From: | Aleksander Alekseev <aleksander(at)timescale(dot)com> |
---|---|
To: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Cc: | haydenwillsim(at)gmail(dot)com |
Subject: | Re: BUG #18544: Setting local config_parameter to DEFAULT behaves unexpectedly when using period in config name |
Date: | 2024-07-18 11:46:41 |
Message-ID: | CAJ7c6TOYLbQzO91SkaOYP765Mb2CnmN1v-EYMHnNdW+DJj3ZVA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Hi,
> However if you call `SET "hasura.user" TO DEFAULT;`, this will actually
> intitialise the value to an empty string.
The documentation for SET says [1]:
"""
DEFAULT can be written to specify resetting the parameter to its
default value (that is, whatever value it would have had if no SET had
been executed in the current session).
"""
And for current_setting() [2]:
"""
Returns the current value of the setting setting_name. If there is no
such setting, current_setting throws an error unless missing_ok is
supplied and is true (in which case NULL is returned).
""
Personally I find it confusing. If no SET had been executed,
current_setting() throws an error because there is no such setting.
Reading this literally I would expect that SET ... DEFAULT should
destroy the setting.
It seems to me that the actual behavior is correct. Even if not,
changing it would mean breaking backward compatibility.
I believe an actionable item would be to better document what SET and
current_setting() do in three cases:
- there is no given setting
- there is a setting with default value
- there is a setting with non-default value
Thoughts?
[1]: /docs/current/sql-set.html
[2]: /docs/current/functions-admin.html
--
Best regards,
Aleksander Alekseev
From | Date | Subject | |
---|---|---|---|
Next Message | Hayden Sim | 2024-07-18 11:58:44 | Re: BUG #18544: Setting local config_parameter to DEFAULT behaves unexpectedly when using period in config name |
Previous Message | PG Bug reporting form | 2024-07-18 09:34:25 | BUG #18544: Setting local config_parameter to DEFAULT behaves unexpectedly when using period in config name |