From: | Darren Duncan <darren(at)darrenduncan(dot)net> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: Should array_length() Return NULL) |
Date: | 2013-03-26 01:10:28 |
Message-ID: | 5150F584.1050203@darrenduncan.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Ants Aasma | 2013-03-26 01:34:49 | Re: Enabling Checksums |
Previous Message | Darren Duncan | 2013-03-26 01:03:56 | Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: Should array_length() Return NULL) |