Re: Application name patch - v4
| От | Marko Kreen |
|---|---|
| Тема | Re: Application name patch - v4 |
| Дата | |
| Msg-id | e51f66da0912011330i216ae892g472270a526e8a73d@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Application name patch - v4 (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-hackers |
On 12/1/09, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Marko Kreen <markokr@gmail.com> writes: > > On 12/1/09, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > >> If you're happy with handling the existing connection parameters in a given > >> way, why would you not want application_name behaving that same way? > > > Well, in pgbouncer case, the parameters tracked via ParamStatus are > > handled transparently. (client_encoding, datestyle, timezone, > > standard_conforming_strings) > > > Hmm, I had not thought about that. Is it sensible to mark > application_name as GUC_REPORT so that pgbouncer can be smart about it? > The actual overhead of such a thing would be probably be unmeasurable in > the normal case where it's only set via the startup packet, but it seems > a bit odd. IMHO it is sensible, if we really want the option to follow client. -- marko
В списке pgsql-hackers по дате отправления: