Hi,
I think the most confusing part is the documentation saying:
"""
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).
"""
It would be expected that subsequent calls to `current_setting()` should throw an error (without the "t" parameter.) As would have been the case if `SET` hadn't ever been executed in the session. This is increasingly confusing when a call to `SET LOCAL "foo.bar" TO 'baz';` runs inside a transaction, as this will affect behaviour outside of the transaction. As can be seen here:
```
psql (16.3 (Ubuntu 16.3-0ubuntu0.24.04.1))
Type "help" for help.
postgres=# SELECT current_setting('foo.bar');
ERROR: unrecognized configuration parameter "foo.bar"
postgres=# BEGIN;
BEGIN
postgres=*# SET LOCAL "foo.bar" TO 'baz';
SET
postgres=*# SELECT current_setting('foo.bar');
current_setting
-----------------
baz
(1 row)
postgres=*# COMMIT;
COMMIT
postgres=# SELECT current_setting('foo.bar');
current_setting
-----------------
(1 row)
```
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
