Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: Should array_length() Return NULL)
От | Darren Duncan |
---|---|
Тема | Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: Should array_length() Return NULL) |
Дата | |
Msg-id | 5150F584.1050203@darrenduncan.net обсуждение исходный текст |
Ответ на | Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: Should array_length() Return NULL) (Darren Duncan <darren@darrenduncan.net>) |
Список | pgsql-hackers |
On 2013.03.25 6:03 PM, Darren Duncan wrote: > On 2013.03.25 5:55 PM, Craig Ringer wrote: >> On 03/25/2013 10:28 PM, Tom Lane wrote: >>> Yeah, they are, because things break when they're set wrong. >> They also make debugging and support harder; you need to get an >> ever-growing list of GUC values from the user to figure out what their >> query does. bytea_output, standard_conforming_strings, etc. Yick. >> >> That said, I don't have a better answer for introducing non-BC changes. > > Given the general trouble GUC values cause, is there a plan to deprecate and > remove each of the existing ones over time? As long as post-removal there isn't > any actual loss of functionality, but users might have to change their code to > do it "the one true way", that would seem a good thing. -- Darren Duncan To clarify, I mean GUC related to backwards compatibility matters, such as bytea_output or standard_conforming_strings, things that affect the logical behavior of code. I don't mean all GUC, not at all, most of the ones I know about should remain configurable. -- Darren Duncan
В списке pgsql-hackers по дате отправления: