Hi, On Monday 30 November 2009 01:16:43 Florian G. Pflug wrote: > 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. Perhaps we should only allow a few parameters to be SET as a connection default - then the pooler would have to issue those just as it has to do for actual connection defaults.
> 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. How would that help the pooler case? The next connection to it might be from a different application. Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers