Re: Application name patch - v4
От | Florian G. Pflug |
---|---|
Тема | Re: Application name patch - v4 |
Дата | |
Msg-id | 4B130EEB.9040605@phlo.org обсуждение исходный текст |
Ответ на | Re: Application name patch - v4 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Application name patch - v4
|
Список | 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 по дате отправления: