Re: Going, going, GUCs!

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: David Fetter <david(at)fetter(dot)org>
Cc: PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Going, going, GUCs!
Date: 2009-10-21 00:43:53
Message-ID: 603c8f070910201743i5c8f16aasd27a34b5dfb3761c@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Oct 20, 2009 at 1:49 PM, David Fetter <david(at)fetter(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-10-21 00:48:43 Re: Could regexp_matches be immutable?
Previous Message Josh Berkus 2009-10-21 00:14:31 Re: alpha2 release notes