On Tue, Oct 13, 2009 at 4:11 PM, Andrew Dunstan <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers