From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Dave Page <dpage(at)pgadmin(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Client application name |
Date: | 2009-10-13 16:55:35 |
Message-ID: | 603c8f070910130955o4f7538a2nb9cf6767daa7fd3d@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Oct 13, 2009 at 12:05 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Dave Page <dpage(at)pgadmin(dot)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,
> 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.
What happens if we want to change the application name after the fact?
Consider the case where there is a connection pooler between the
database and application, for example.
...Robert
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-10-13 17:10:05 | Re: COPY enhancements |
Previous Message | Andres Freund | 2009-10-13 16:49:13 | Re: Client application name |