Re: Client application name

From: Dave Page <dpage(at)pgadmin(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Client application name
Date: 2009-10-15 13:56:34
Message-ID: 937d27e10910150656gc8574edj6b24247861089e45@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Oct 14, 2009 at 3:42 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Sure.  I'm envisioning that what the env variable or connection option
> actually does is cause libpq to include a SET command for a GUC
> variable in the initial connection request packet.  Compare, say,
> PGCLIENTENCODING -> client_encoding.

So you can now do any of the following to set the application name:

- Set $PGAPPLICATIONNAME on the client, prior to connection.
- Include 'application_name=MyCoolApp' in the PQconnectdb connection string.
- Use SET application_name

Currently though, pg_dump and psql (and presumably their close
friends) use PQsetdbLogin to establish their connection. Would it be
preferred if I:

a) Added PQsetdbLogin2() with an additional option for the application
name (my guess is 'no').
b) Updated the apps to use PQconnectdb
c) Something else?

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dave Page 2009-10-15 14:08:32 Re: Rejecting weak passwords
Previous Message Kevin Grittner 2009-10-15 13:49:29 Re: Rejecting weak passwords