Re: GUC_REPORT for protocol tunables was: Re: Optimize binary serialization format of arrays with fixed size elements
От | Robert Haas |
---|---|
Тема | Re: GUC_REPORT for protocol tunables was: Re: Optimize binary serialization format of arrays with fixed size elements |
Дата | |
Msg-id | CA+TgmoZvFfFW6qktzfbozzBX6MUJp_3UhMP+_ywHGC4oyzF67g@mail.gmail.com обсуждение исходный текст |
Ответ на | GUC_REPORT for protocol tunables was: Re: Optimize binary serialization format of arrays with fixed size elements (Marko Kreen <markokr@gmail.com>) |
Ответы |
Re: GUC_REPORT for protocol tunables was: Re: Optimize binary serialization format of arrays with fixed size elements
|
Список | pgsql-hackers |
On Mon, Jan 23, 2012 at 9:59 AM, Marko Kreen <markokr@gmail.com> wrote: > On Sun, Jan 22, 2012 at 11:47 PM, Mikko Tiihonen > <mikko.tiihonen@nitorcreations.com> wrote: >> * introduced a new GUC variable array_output copying the current >> bytea_output type, with values "full" (old value) and >> "smallfixed" (new default) >> * added documentation for the new GUC variable > > If this variable changes protocol-level layout > and is user-settable, shouldn't it be GUC_REPORT? > > Now that I think about it, same applies to bytea_output? > > You could say the problem does not appear if the > clients always accepts server default. But how can > the client know the default? If the client is required > to do "SHOW" before it can talk to server then that > seems to hint those vars should be GUC_REPORT. > > Same story when clients are always expected to set > the vars to their preferred values. Then you get > clients with different settings on one server. > This breaks transaction-pooling setups (pgbouncer). > Again, such protocol-changing tunables should be > GUC_REPORT. Probably so. But I think we need not introduce quite so many new threads on this patch. This is, I think, at least thread #4, and that's making the discussion hard to follow. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: