From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Dave Page <dpage(at)pgadmin(dot)org> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Client application name |
Date: | 2009-10-20 19:55:22 |
Message-ID: | 4421.1256068522@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2009-10-20 19:57:28 | Re: Privileges and inheritance |
Previous Message | Pavel Stehule | 2009-10-20 19:39:50 | Re: Controlling changes in plpgsql variable resolution |