Re: Client application name

Dave Page wrote:
> On Tue, Oct 20, 2009 at 8:55 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Dave Page <dpage(at)pgadmin(dot)org> writes:
>>> I just realised there's a nasty problem with this. In my client
>>> application, I can use PQconninfoParse to determine if
>>> application_name (or fallback_application_name) are valid connection
>>> string options for the version of libpq that I have.
>>> However, there is no way that I can see of doing a comparable test in
>>> libpq itself, to ensure that the server understands the parameter, so
>>> if I connect to an 8.5 server, everything works fine, but if connect
>>> to an older server with my new libpq, the connection fails because of
>>> the unknown parameter in the startup packet.
>> Hmm, yeah, that's a good point. It seems like you will have to send the
>> appname SET command as a separate packet, after you have gotten the
>> initial response and know what version the server is. Kind of annoying
>> from a performance standpoint, but I believe it won't be too hard to
>> shoehorn into libpq --- it already has a code path for that for older
>> servers, IIRC.
>
> Yeah - unfortunately that means the connection log messages won't be
> able to include the appname (I had to tweak ProcessStatupPacket() to
> deal with it earlier as it was).

Looking at the way we process the startup packet in
ProcessStartupPacket, there's one dirty hack you could do. As the code
stands, if you specify "options" key/value pair more than once, the
latter value overrides the first one. If we change that in PG 8.5 so
that the values are concatenated instead, you can put app name into the
first "options" line, and other options (or an empty string) into the
second. Pre-8.5 servers will silently ignore the first line.

Another idea is to do something similar to the 'prefer' SSL mode, or if
the server doesn't support protocol version 3: Try with the GUC in
startup packet first, and if that fails, retry without it.

I'm not sure if I like either of those better than the extra SET
command, but I thought I'd mention it.

> Should we perhaps change the behaviour of the backend to give a
> warning only for unknown settings in the startup packet? It doesn't
> seem beyond the realms of possibility that we might want to add
> something else in the future, and this will at least mean that in a
> few releases time it might be reasonably safe to do so.

Yeah, sounds like a good idea. But what if there's options that we would
*want* to throw an error on if the server doesn't understand them? It
would be better if the client could explicitly mark optional arguments
somehow.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com