| 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-14 14:42:09 |
| Message-ID: | 13100.1255531329@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 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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dave Page | 2009-10-14 14:53:40 | Re: Client application name |
| Previous Message | Peter Eisentraut | 2009-10-14 14:35:59 | alpha 2 release notes |