Re: Client application name - Mailing list pgsql-hackers

From Dave Page
Subject Re: Client application name
Date
Msg-id 937d27e10910150738j375ae826s9f48d7df22d21da5@mail.gmail.com
Whole thread Raw
In response to Re: Client application name  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Client application name
List pgsql-hackers
On Thu, Oct 15, 2009 at 3:28 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Dave Page <dpage@pgadmin.org> writes:
>> 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?
>
> a) is absolutely right out.  b) is okay from an overall viewpoint but
> you would find yourself doing something very much like this:
> http://archives.postgresql.org/message-id/3073cc9b0909141123s7ec779a0h6524ec90a0a81c7@mail.gmail.com
> So I would suggest
> d) leave the issue unsolved until some descendant of that patch gets
> committed, and then use it.

Ooh, I like that patch. I'll wait for that.

> There is also
> e) do nothing, since the environment var and SET options are plenty.
>
> Also, I am wondering exactly what you think psql would *do* with the
> parameter if it had it.  If the answer is "force the setting to be
> 'psql'", that's the wrong answer.  IMO you'd really want the environment
> variable to take precedence over that, if set.  But libpq considers the
> priority to go the other way.

Well in the psql case, it could flip that priority itself and only set
the value if the environment variable wasn't set - which I agree would
seem the right thing to do. On further thought, it would seem
reasonable to do the same in the other apps as well, so you could have
your backup script do something like "PGAPPLICATIONNAME="Nightly
backup" /usr/bin/pg_dump ..."

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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Trigger with WHEN clause (WIP)
Next
From: "Albe Laurenz"
Date:
Subject: Re: Rejecting weak passwords