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
signature.asc
Description: OpenPGP digital signature
