Re: Client application name - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Client application name
Date
Msg-id 804.1255621027@sss.pgh.pa.us
Whole thread Raw
In response to Re: Client application name  (Dave Page <dpage@pgadmin.org>)
Responses Re: Client application name
List pgsql-hackers
Dave Page <dpage@pgadmin.org> writes:
> On Thu, Oct 15, 2009 at 3:50 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Hmm. �Maybe this is a generic problem. �Should libpq offer some sort
>> of help? �Maybe a "secondaryappname" parameter that doesn't override
>> the env variable.

> is it worth uglifying libpq? All we're talking about is something like:

> if (!getenv("PGAPPLICATIONNAME"))
>     strncat(connstr, " application_name=psql", sizeof(connstr) -
> strlen(connstr) - 1);

Well, per earlier discussion we're not really interested in doing this
with connection strings, it's going to be some sort of parameter array
deal.  This approach might require a read-write instead of constant
parameter array (depending on how the other patch eventually works out).
But the main thing that's bugging me about it is the explicit knowledge
on the application's part that there is an environment variable that
interacts with this setting.  Seems ugly and badly-factored.

Another possibility that should be mentioned for the record is that
we could special-case the appname parameter inside libpq, so that the
environment variable takes precedence over the conn setting instead
of the other way round.  That seems pretty ugly too, but maybe it's
the least bad answer, if we decide that most apps need that precedence.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: EXPLAIN BUFFERS
Next
From: Dave Page
Date:
Subject: Re: Client application name