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
