Обсуждение: custom parameters cannot be removed once set

Today I was reminded of an issue I have run across before, namely that
in a given postgres session, once a custom parameter has been set, there
is no way to remove it entirely. For example:

8<-------------------
# psql regression
psql (9.5rc1)
Type "help" for help.

regression=# SELECT current_setting('app_name.app_user');
ERROR:  unrecognized configuration parameter "app_name.app_user"
regression=# BEGIN;
BEGIN
regression=# SET LOCAL app_name.app_user = 'bob';
SET
regression=# SELECT current_setting('app_name.app_user');current_setting
-----------------bob
(1 row)

regression=# ROLLBACK;
ROLLBACK
regression=# SELECT current_setting('app_name.app_user');current_setting
-----------------

(1 row)

regression=# RESET app_name.app_user;
RESET
regression=# SELECT current_setting('app_name.app_user');current_setting
-----------------

(1 row)

regression=# SELECT current_setting('app_name.app_user') = '';?column?
----------t
(1 row)
8<-------------------

Note that before app_name.app_user has been set the first time, an error
is thrown if we try to access it. However once it has been set, even
when done as SET LOCAL and inside a rolled back transaction, the
parameter continues to exist and no error is thrown when reading it. And
it is not even NULL, it is actually an empty string.

This strikes me as, at least, surprising, and possibly should be
considered a bug. Thoughts?

A side issue is that it would be nice if there were a way to check for a
custom parameter value without getting an error if it does not exist.
There is a missing_ok option to GetConfigOptionByName(), but we
currently don't expose it from SQL. I'd like to add a variant of
current_setting() with a second argument for missing_ok. Objections?

Thanks,

Joe

--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development

Joe Conway <mail@joeconway.com> writes:
> Today I was reminded of an issue I have run across before, namely that
> in a given postgres session, once a custom parameter has been set, there
> is no way to remove it entirely.

True.

> This strikes me as, at least, surprising, and possibly should be
> considered a bug. Thoughts?

Meh.  The real problem here is that people are abusing the custom-GUC
mechanism to implement session-lifespan variables.  I do not think we
should encourage that; GUC offers neither adequate features for that
(eg, no way to declare a variable's type) nor adequate performance
(it's not going to scale to very many variables).

I'd rather see us invent a real session-variable mechanism instead
of putting yet more demands on GUC that have nothing to do with its
primary mission, and indeed are antithetical to it.
        regards, tom lane

On 12/30/2015 10:36 AM, Joe Conway wrote:
> A side issue is that it would be nice if there were a way to check for a
> custom parameter value without getting an error if it does not exist.
> There is a missing_ok option to GetConfigOptionByName(), but we
> currently don't expose it from SQL. I'd like to add a variant of
> current_setting() with a second argument for missing_ok. Objections?

Nevermind this part -- I guess someone already beat me to it :-)

Joe

--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development

On 12/30/2015 10:44 AM, Tom Lane wrote:
> Meh.  The real problem here is that people are abusing the custom-GUC
> mechanism to implement session-lifespan variables.  I do not think we
> should encourage that; GUC offers neither adequate features for that
> (eg, no way to declare a variable's type) nor adequate performance
> (it's not going to scale to very many variables).

All true, but it works well enough today that it serves an often needed
role. And it is plenty fast, at least for use cases for which I've
needed it.

> I'd rather see us invent a real session-variable mechanism instead
> of putting yet more demands on GUC that have nothing to do with its
> primary mission, and indeed are antithetical to it.

Also true, but since no such effort exists today that I'm aware of,
there is little chance we will have that real mechanism any time in the
next 24 months at the least, because I doubt even the bikeshedding could
be finished before we lock down 9.6 :-(

Joe

--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development