From: | Dave Page <dpage(at)pgadmin(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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-14 14:53:40 |
Message-ID: | 937d27e10910140753o88ca1c4vd4c957af24108545@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Oct 14, 2009 at 3:42 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Dave Page <dpage(at)pgadmin(dot)org> writes:
>> On Tue, Oct 13, 2009 at 10:25 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> We have several things already that can be fed either from an
>>> environment variable or an option in the connection string.
>>> Is there any compelling reason why those two mechanisms aren't
>>> adequate for this?
>
>> Err, yes - see above. And didn't you also say it was essential to be
>> able to change it after the initial connection (for which the GUC
>> seems like the obvious solution)?
>
> Sure. I'm envisioning that what the env variable or connection option
> actually does is cause libpq to include a SET command for a GUC
> variable in the initial connection request packet. Compare, say,
> PGCLIENTENCODING -> client_encoding.
Right - I think we're just misunderstanding each other whilst we're
saying the same thing. I want the envvar/connection string option as
ways to setup the value at connection time, and the use of SET
available for later changes.
--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Roger Leigh | 2009-10-14 14:59:00 | Re: Unicode UTF-8 table formatting for psql text output |
Previous Message | Tom Lane | 2009-10-14 14:42:09 | Re: Client application name |