On Tue, Oct 13, 2009 at 5:05 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Dave Page <dpage@pgadmin.org> writes:
>> - Is my approach reasonable?
>> - What interface should I include in libpq?
>
> I thought the plan was to have libpq look at an environment variable,
I wasn't aware we had a plan :-)
> compare PGCLIENTENCODING for example. I'm not convinced psql should be
> involved in the logic at all --- if it is, there definitely must be a
> way for scripts to override the "psql" value. In general the place that
> is most reasonable to set the value might be several software levels up
> from libpq, which is what makes the environment-variable approach
> attractive.
The current implementation just has psql do SET application_name =
'psql'; immediately following connection to setup a sensible default.
That can be overridden at any time with another SET.
I can have libpq look at the environment as it does for
PGCLIENTENCODING, but I'd certainly like to be able to use the
connection string as well, as environment variables are not really the
first choice of a Windows programmer for such things. I'm not sure
psql should be looking directly at the environment though should it?
Or would you envisage it only SETing application_name itself, if libpq
didn't already have a value from elsewhere?
--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
