Re: Client application name
От | Dave Page |
---|---|
Тема | Re: Client application name |
Дата | |
Msg-id | 937d27e10910140753o88ca1c4vd4c957af24108545@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Client application name (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Wed, Oct 14, 2009 at 3:42 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Dave Page <dpage@pgadmin.org> writes: >> On Tue, Oct 13, 2009 at 10:25 PM, Tom Lane <tgl@sss.pgh.pa.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
В списке pgsql-hackers по дате отправления: