Re: [HACKERS] custom parameters cannot be removed once set

[Joe Conway]

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



signature.asc
Description: OpenPGP digital signature

Re: [HACKERS] custom parameters cannot be removed once set

[Joe Conway]

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



signature.asc
Description: OpenPGP digital signature

Re: [HACKERS] custom parameters cannot be removed once set

[Tom Lane]

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers