Re: BUG #18544: Setting local config_parameter to DEFAULT behaves unexpectedly when using period in config name

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)
```

Thank you,
Hayden

On Thu, Jul 18, 2024 at 9:46 PM Aleksander Alekseev <
aleksander(at)timescale(dot)com> wrote:

> 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
>