Re: Remove array_nulls? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Remove array_nulls?
Date
Msg-id 20138.1450459524@sss.pgh.pa.us
Whole thread Raw
In response to Re: Remove array_nulls?  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Remove array_nulls?
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Dec 18, 2015 at 12:10 PM, Andres Freund <andres@anarazel.de> wrote:
>> I'm saying that 10 year deprecation periods don't make sense. Either we
>> decide to remove the compat switch because we dislike it for $reasons,
>> in which case it should be removed sooner. Or we decide to keep the
>> switch indefinitely.

> Forever is an awfully long time.  I think that it's OK to remove
> backward-compatibility features at some point even if they're not
> really harming anything.  I think the time before we do that should be
> long, but I don't think it needs to be forever.

Maybe I shouldn't put words in Andres' mouth, but I don't think that by
"indefinitely" he meant "forever".  I read that more as "until some
positive reason to remove it arrives".  I could imagine that at some point
we decide to do a wholesale cleanup of backwards-compatibility GUCs, and
then we'd zap this one along with others.

By itself, though, array_nulls seems about as harmless as such things get.
The sum total of the code simplification we'd get from removing it is
that the first segment of this if-test would go away:
       if (Array_nulls && !hasquoting &&           pg_strcasecmp(itemstart, "NULL") == 0)

So there's no plausible argument that it's causing development problems.

I am mindful of Josh's frequent complaint that we have too many GUCs,
which is a legitimate concern; but removing just one won't do much
for that.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [PATCH] Copy-pasteo in logical decoding
Next
From: Robert Haas
Date:
Subject: Re: Remove array_nulls?