Re: Application name patch - v4 - Mailing list pgsql-hackers

From Florian G. Pflug
Subject Re: Application name patch - v4
Date
Msg-id 4B130EEB.9040605@phlo.org
Whole thread Raw
In response to Re: Application name patch - v4  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Application name patch - v4
List 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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Application name patch - v4
Next
From: Fujii Masao
Date:
Subject: Re: Application name patch - v4