Dimitri Fontaine <dfonta...@hi-media.com> writes:
> Le 29 nov. 2009 à 18:22, Tom Lane a écrit :
>>> I think we should use GUC_NO_RESET_ALL.
>>
>> I agree with you, but it seems we have at least as many votes to not do
>> that. Any other votes out there?
> Driven by the pooler use case (pgbouncer, even), I'd say RESET ALL should
> reset also the application name. And the connection value is not tied any
> more to something sensible as soon as you have pooling in there...
The thing is that the libpq API treats application_name as a *property
of the connection*. You shouldn't expect it to go away on RESET ALL,
any more than you'd expect RESET ALL to cause you to be reconnected to
some other database.
If a pooler wants application_name to be cleared when it issues RESET
ALL, I think it ought to be setting the name via SET, not via the libpq
connection option.
But it's certainly true that using GUC_NO_RESET_ALL would be a quick
kluge rather than a proper solution. Andres Freund suggested upthread
that we should fix this by extending SET:
: One possibility would be to make it possible to issue SETs that behave
: as if set in a startup packet - imho its an implementation detail that
: SET currently is used.
I think there's a good deal of merit in this, and it would't be hard at
all to implement, seeing that we already have SET LOCAL and SET SESSION.
We could add a third keyword, say SET DEFAULT, that would have the
behavior of setting the value in a fashion that would persist across
resets. I'm not sure that DEFAULT is exactly le mot juste here, but
agreeing on a keyword would probably be the hardest part of making it
happen.
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
