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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
