Re: Going, going, GUCs! - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Going, going, GUCs!
Date
Msg-id 603c8f070910201743i5c8f16aasd27a34b5dfb3761c@mail.gmail.com
Whole thread Raw
In response to Going, going, GUCs!  (David Fetter <david@fetter.org>)
Responses Re: Going, going, GUCs!
List pgsql-hackers
On Tue, Oct 20, 2009 at 1:49 PM, David Fetter <david@fetter.org> wrote:
> Folks,
>
> I'd like to see about removing the following GUCs:
>
> add_missing_from (should be off)
> array_nulls (should be on)
> commit_delay (no need for this knob)
> commit_siblings (no need for this knob)
> default_with_oids (should be off)
> password_encryption (should be on)
> regex_flavor (should be advanced, regex flavor can be controlled on a per-regex basis when they're advanced)
> sql_inheritance (should be on)
> standard_conforming_strings (should be on)
> synchronize_seqscans (should be on)
> track_activities (should be on)
> track_counts (should be on)
> transform_null_equals (should probably be off)
> update_process_title (should be on)
>
> What say on each?  When?

We just had a conversation about whether or not to massively break
backward compatibility.  The consensus was, as I'm sure you are aware,
was "no".  So why bring it up again, and with absolutely zero
justification for the proposed changes?  Each and every knob on this
list was added for some reason, and we should remove it when, and only
when, that reason either no longer applies, or there is some
countervailing reason.

...Robert


pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: alpha2 release notes
Next
From: Tom Lane
Date:
Subject: Re: Could regexp_matches be immutable?