Re: BUG #18544: Setting local config_parameter to DEFAULT behaves unexpectedly when using period in config name
От | Aleksander Alekseev |
---|---|
Тема | Re: BUG #18544: Setting local config_parameter to DEFAULT behaves unexpectedly when using period in config name |
Дата | |
Msg-id | CAJ7c6TOYLbQzO91SkaOYP765Mb2CnmN1v-EYMHnNdW+DJj3ZVA@mail.gmail.com обсуждение исходный текст |
Ответ на | BUG #18544: Setting local config_parameter to DEFAULT behaves unexpectedly when using period in config name (PG Bug reporting form <noreply@postgresql.org>) |
Ответы |
Re: BUG #18544: Setting local config_parameter to DEFAULT behaves unexpectedly when using period in config name
|
Список | 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]: https://www.postgresql.org/docs/current/sql-set.html [2]: https://www.postgresql.org/docs/current/functions-admin.html -- Best regards, Aleksander Alekseev
В списке pgsql-bugs по дате отправления: