Re: Application name patch - v4

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Nov 30, 2009 at 4:54 PM, Dimitri Fontaine
> <dfontaine(at)hi-media(dot)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