Re: Client application name

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Client application name
Дата
Msg-id 804.1255621027@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Client application name  (Dave Page <dpage@pgadmin.org>)
Ответы Re: Client application name  (Dave Page <dpage@pgadmin.org>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: EXPLAIN BUFFERS
Следующее
От: Dave Page
Дата:
Сообщение: Re: Client application name