Robert Haas <robertmh...@gmail.com> writes: > On Mon, Nov 30, 2009 at 4:54 PM, Dimitri Fontaine > <dfonta...@hi-media.com> wrote: >> Le 30 nov. 2009 à 22:38, Robert Haas a écrit : >>> I still don't really understand why we wouldn't want RESET ALL to >>> reset the application name. In what circumstances would you want the >>> application name to stay the same across a RESET ALL? >> >> I can't see any use case, but SET/RESET is tied to SESSION whereas >> application_name is a CONNECTION property. So it's a hard sell that reseting >> the session will change connection properties.
> Is there any technical difference between a connection property and a > session property? If so, what is it? The point is that every other thing you can set in a libpq connection string is persistent throughout the connection. For the ones that you can change at all, such as client_encoding, *RESET ALL actually resets it to what was specified in the connection string*. It does not satisfy the POLA for application_name to behave differently. I think the argument about poolers expecting something different is hogwash. A pooler would want RESET ALL to revert the connection state to what it was at establishment. That would include whatever application name the pooler would have specified when it started the connection, I should think. The only reason we're even having this discussion is that libpq isn't able to make application_name work exactly like its other connection parameters because of the backwards-compatibility issue. Maybe we should think a bit harder about that. Or else give up having libpq manage it like a connection parameter. 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