Re: Client application name

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dave Page <dpage(at)pgadmin(dot)org>
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 15:37:07
Message-ID: 804.1255621027@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dave Page <dpage(at)pgadmin(dot)org> writes:
> On Thu, Oct 15, 2009 at 3:50 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dave Page 2009-10-15 15:46:57 Re: Client application name
Previous Message Robert Haas 2009-10-15 15:34:51 Re: EXPLAIN BUFFERS