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