On Tue, Oct 20, 2009 at 8:55 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Dave Page <dpage@pgadmin.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).
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.
--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
PGDay.EU 2009 Conference: http://2009.pgday.eu/start