On Tue, Oct 13, 2009 at 4:11 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
>
>> On the second question, obviously the user can call SET to set a
>> value, as I've done for now in psql, however in other DBMSs, it may be
>> set in the connection string. My feeling would be to do that, and
>> possibly add PQsetApplicationName(PGconn *conn, char *name) and char
>> *PQapplicationName(PGconn *conn);. What do others think?
>>
>>
>
>
> Doing it with a GUC will not be nearly so useful as having it in the wire
> protocol, IMNSHO. Just one example: it wouldn't be present in connection
> records, because it wouldn't be set yet.
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.
Am I missing a way around this?
--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
PGDay.EU 2009 Conference: http://2009.pgday.eu/start
