From: | "Florian G(dot) Pflug" <fgp(at)phlo(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Dave Page <dpage(at)pgadmin(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Application name patch - v4 |
Date: | 2009-11-30 00:16:43 |
Message-ID: | 4B130EEB.9040605@phlo.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> : 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.
Hm, but without a way to prevent the users of a connection pool from
issuing "SET DEFAULT", that leaves a connection pool with no way to
revert a connection to a known state.
How about "SET CONNECTION", with an additional GUC called
connection_setup which can only be set to true, never back to false.
Once connection_setup is set to true, further SET CONNECTION attempts
would fail.
In a way, this mimics startup-packet SETs without actually doing things
in the startup packet.
best regards,
Florian Pflug
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2009-11-30 01:01:55 | Re: Application name patch - v4 |
Previous Message | Tom Lane | 2009-11-29 23:25:29 | Re: Application name patch - v4 |