| From: | Euler Taveira de Oliveira <euler(at)timbira(dot)com> |
|---|---|
| To: | Dave Page <dpage(at)pgadmin(dot)org> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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 14:22:42 |
| Message-ID: | 4AD73032.2050606@timbira.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Dave Page escreveu:
> 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
>
Works for me.
> 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?
>
My prefered option is (b). But it should be a separate patch.
--
Euler Taveira de Oliveira
http://www.timbira.com/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2009-10-15 14:28:27 | Re: Client application name |
| Previous Message | Dave Page | 2009-10-15 14:08:32 | Re: Rejecting weak passwords |