Re: [HACKERS] Remove array_nulls?

[Robert Treat]

On Thu, Dec 17, 2015 at 4:31 PM, Robert Haas  wrote:
> On Wed, Dec 16, 2015 at 10:48 PM, Jim Nasby  wrote:
>> IIUC, that means supporting backwards compat. GUCs for 10 years, which seems
>> a bit excessive. Granted, that's about the worse-case scenario for what I
>> proposed (ie, we'd still be supporting 8.0 stuff right now).
>
> Not to me.  GUCs like array_nulls don't really cost much - there is no
> reason to be in a hurry about removing them that I can see.
>

Perhaps not with rock solid consistency, but we've certainly used the
argument of the "not a major major version release" to shoot down
introducing incompatible features / improvements (protocol changes
come to mind), which further lends credence to Jim's point about
people expecting backwards incompatible breakage to be in a major
major version changes.

Given the overhead from a development standpoint is low, whats the
better user experience: delay removal for as long as possible (~10
years) to narrow the likely of people being affected, or make such
changes as visible as possible (~6+ years) so that people have clear
expectations / lines of demarcation?

Robert Treat
play: xzilla.net
work: omniti.com


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Remove array_nulls?

[Robert Haas]

On Fri, Dec 18, 2015 at 9:52 AM, Robert Treat  wrote:
> On Thu, Dec 17, 2015 at 4:31 PM, Robert Haas  wrote:
>> On Wed, Dec 16, 2015 at 10:48 PM, Jim Nasby  wrote:
>>> IIUC, that means supporting backwards compat. GUCs for 10 years, which seems
>>> a bit excessive. Granted, that's about the worse-case scenario for what I
>>> proposed (ie, we'd still be supporting 8.0 stuff right now).
>>
>> Not to me.  GUCs like array_nulls don't really cost much - there is no
>> reason to be in a hurry about removing them that I can see.
>>
>
> Perhaps not with rock solid consistency, but we've certainly used the
> argument of the "not a major major version release" to shoot down
> introducing incompatible features / improvements (protocol changes
> come to mind), which further lends credence to Jim's point about
> people expecting backwards incompatible breakage to be in a major
> major version changes.

My memory is that Tom usually argues pretty vigorously against the
idea that there's anything special about a first-digit bump in terms
of incompatibilities.  But your memory may have a longer reach than
mine.

> Given the overhead from a development standpoint is low, whats the
> better user experience: delay removal for as long as possible (~10
> years) to narrow the likely of people being affected, or make such
> changes as visible as possible (~6+ years) so that people have clear
> expectations / lines of demarcation?

IMHO, it's almost hopeless to expect users to prepare for incompatible
changes we want to make.  When we try to force it, as we did with
standard_conforming_strings or the 8.3-vintage casting changes, we
cause a lot of user pain and that's about it.  People don't say "ah,
these changes are coming, I need to adjust my app to be safe in this
new world"; instead, they say "crap, I can't upgrade, PostgreSQL
hackers suck".  We spend our days and nights worrying about this
stuff, but real users don't.  They just got knocked over when the
change hits.  Or the people who understand that the problem is coming
are in a different group than the people who have to fix it, so it
doesn't get fixed.  Or whatever.

My experience is that it is very common for users to upgrade across a
whole series of releases at the same time.  People don't upgrade from
8.3 to 8.4 and then to 9.0, or even from 8.3 to 9.0 to 9.2.  I mean,
some do.  But people doing things like 8.2 -> 9.3 is not that
uncommon, at least in my experience with EnterpriseDB customers.
That's why we support releases for five full years, right?  So that
people don't necessarily have to upgrade more than about that often.
Ideally they'd upgrade about every 4 years, so that they get off the
oldest supported release before it actually drops out of support, but
for various reasons it often takes longer than that, and their current
version is out of support before they get around to upgrading.  We can
wag our tongues and cluck at those people, but when we're quick to
pull the trigger on removing backward compatibility hacks, we actually
make the problem worse, not better.  Now people stay on the old
versions even longer, because they can't upgrade until they fix their
app.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Remove array_nulls?

[Alvaro Herrera]

Robert Haas wrote:
> On Fri, Dec 18, 2015 at 9:52 AM, Robert Treat  wrote:

> > Perhaps not with rock solid consistency, but we've certainly used the
> > argument of the "not a major major version release" to shoot down
> > introducing incompatible features / improvements (protocol changes
> > come to mind), which further lends credence to Jim's point about
> > people expecting backwards incompatible breakage to be in a major
> > major version changes.
> 
> My memory is that Tom usually argues pretty vigorously against the
> idea that there's anything special about a first-digit bump in terms
> of incompatibilities.  But your memory may have a longer reach than
> mine.

We haven't made a lot of first-digit changes, and if I recall correctly
it has been mostly a matter of PR, based on sets of particular features,
rather than objective technical criteria (such as changes in backwards
compatibility or such).  For instance we changed from 7 to 8 mostly
because of adding the Windows port and PITR, and from 8 to 9 because of
replication -- you could think of those as major steering changes, with
large influence in what came afterwards.

I don't know what would be a good reason to change from 9 to 10, but
certainly we shouldn't do it just to remove a couple of GUCs -- much
less do it for no reason at all (which would be what "but 9.6 is too
close to 9.10 already" would boil down to.)  I sure hope we're gonna
find some good reason to do it before 9.10 actually comes around.

> > Given the overhead from a development standpoint is low, whats the
> > better user experience: delay removal for as long as possible (~10
> > years) to narrow the likely of people being affected, or make such
> > changes as visible as possible (~6+ years) so that people have clear
> > expectations / lines of demarcation?
> 
> IMHO, it's almost hopeless to expect users to prepare for incompatible
> changes we want to make.  When we try to force it, as we did with
> standard_conforming_strings or the 8.3-vintage casting changes, we
> cause a lot of user pain and that's about it.  People don't say "ah,
> these changes are coming, I need to adjust my app to be safe in this
> new world"; instead, they say "crap, I can't upgrade, PostgreSQL
> hackers suck".  We spend our days and nights worrying about this
> stuff, but real users don't.  They just got knocked over when the
> change hits.

Agreed on this.  (As anecdote, I remember people relying on
add_missing_from, and never fixing the apps, until they absolutely had
no choice because the GUC was removed, even though I warned years in
advance.)

On the other hand, while I agree with you that we should strive to
maintain backwards compatible options for a long time, and that in this
particular case I see no reason not to wait a few more releases since it
doesn't hurt anything, I don't think we should make this an iron-clad
rule: I imagine there might be cases where there will be good reasons to
break it sooner than those 10 years if maintenance becomes a serious
problem otherwise.  We will need to discuss each case individually as it
comes up.

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Remove array_nulls?

[Andres Freund]

On 2015-12-18 12:06:43 -0500, Robert Haas wrote:
> Well, Tom, Alvaro, and I all pretty much said that removing things
> when it's blocking further development makes sense, but that there's
> no hurry to remove anything else.  That sounds like what you are
> saying, too.  So what's the actual disagreement here?

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.


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Remove array_nulls?

[Tom Lane]

I wrote:
> Not entirely sure what to make of this.  It occurs to me that the "it
> breaks immutability" argument might apply to array_nulls, though I've
> not done any legwork to confirm or disprove that.  If it doesn't apply,
> though, I'm leaning to the position that there's no reason to remove
> array_nulls.

OK, I went and looked.  Array_nulls is consulted only in array_in(),
which is marked stable (and would need to be so marked even without
this consideration, since the array element type's input function
might only be stable).  So it's not breaking any rules.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Remove array_nulls?

[Joshua D. Drake]

On 12/18/2015 09:12 AM, Robert Haas wrote:

On Fri, Dec 18, 2015 at 12:10 PM, Andres Freund  wrote:

On 2015-12-18 12:06:43 -0500, Robert Haas wrote:

Well, Tom, Alvaro, and I all pretty much said that removing things
when it's blocking further development makes sense, but that there's
no hurry to remove anything else.  That sounds like what you are
saying, too.  So what's the actual disagreement here?


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.


Why not just keep it at the same rate as our support policy? The feature 
gets 5 years, then it is removed.


JD



--
Command Prompt, Inc. - http://www.commandprompt.com/  503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Announcing "I'm offended" is basically telling the world you can't
control your own emotions, so everyone else should do it for you.


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Remove array_nulls?

[Robert Haas]

On Fri, Dec 18, 2015 at 11:08 AM, Alvaro Herrera
 wrote:
> I don't know what would be a good reason to change from 9 to 10, but
> certainly we shouldn't do it just to remove a couple of GUCs -- much
> less do it for no reason at all (which would be what "but 9.6 is too
> close to 9.10 already" would boil down to.)  I sure hope we're gonna
> find some good reason to do it before 9.10 actually comes around.

I don't want to toot my own horn too much here, but I think parallel
query might be an appropriate milestone.  If we don't get any more
than what we have now done for this release, well, no, probably not.
But what if we get the parallel join stuff I've posted and the work
David Rowley and Haribabu Kommi are doing on parallel aggregate done?
At that point I think it starts to get pretty interesting.  Sure,
there will be plenty of work left to do, but that's often true: 9.0
introduced streaming replication and Hot Standby, but they got a lot
more usable in 9.1.

> On the other hand, while I agree with you that we should strive to
> maintain backwards compatible options for a long time, and that in this
> particular case I see no reason not to wait a few more releases since it
> doesn't hurt anything, I don't think we should make this an iron-clad
> rule: I imagine there might be cases where there will be good reasons to
> break it sooner than those 10 years if maintenance becomes a serious
> problem otherwise.  We will need to discuss each case individually as it
> comes up.

Right.  If a particular backward-compatibility flag is preventing
important improvements, that's a good argument for phasing it out
sooner.  But that's certainly not the case with array_nulls so, uh,
who cares?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Remove array_nulls?

[Tom Lane]

"David G. Johnston"  writes:
> On Fri, Dec 18, 2015 at 10:25 AM, Tom Lane  wrote:
>> 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.

>​Hand-waving from me but I see a "positive reason" being that someone wants
> to write and commit a patch that does not play nicely with the old
> behavior.

Sure, that's also possible.  But no such patch is on the table now.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Remove array_nulls?

[Tom Lane]

Robert Haas  writes:
> My experience is that it is very common for users to upgrade across a
> whole series of releases at the same time.  People don't upgrade from
> 8.3 to 8.4 and then to 9.0, or even from 8.3 to 9.0 to 9.2.  I mean,
> some do.  But people doing things like 8.2 -> 9.3 is not that
> uncommon, at least in my experience with EnterpriseDB customers.
> That's why we support releases for five full years, right?  So that
> people don't necessarily have to upgrade more than about that often.

Yeah.  For a recent example, see yesterday's thread with someone inquiring
about known bugs in 8.1 ... and they did not sound like they had any
intention of getting off that soon.  But when they do, they're going to
have eight or ten years' worth of incompatibilities to deal with.

I did a quick troll through the commit log looking for previous cases
where we have removed backwards-compatibility GUCs.  I could find only
two:


commit ab61df9e527dcedbd3bbefbcb8b634b0b72f2ad5
Author: Tom Lane 
Date:   Wed Oct 21 20:38:58 2009 +

Remove regex_flavor GUC, so that regular expressions are always "advanced"
style by default.  Per discussion, there seems to be hardly anything that
really relies on being able to change the regex flavor, so the ability to
select it via embedded options ought to be enough for any stragglers.
Also, if we didn't remove the GUC, we'd really be morally obligated to
mark the regex functions non-immutable, which'd possibly create performance
issues.

commit 289e2905c82fc37f8b82b088bb823742aad4bb68
Author: Tom Lane 
Date:   Wed Oct 21 20:22:38 2009 +

Remove add_missing_from GUC and associated parser support for "implicit 
RTEs".
Per recent discussion, add_missing_from has been deprecated for long enough 
to
consider removing, and it's getting in the way of planned parser 
refactoring.
The system now always behaves as though add_missing_from were OFF.


So in both those cases, there was an active reason to remove the GUC,
not just "it seems like this is too old for anyone to want it anymore".

Also worthy of remark is that add_missing_from and regex_flavor were both
added in 2003, so their useful lifespan was a lot shorter than what's
being suggested in this thread.

Not entirely sure what to make of this.  It occurs to me that the "it
breaks immutability" argument might apply to array_nulls, though I've
not done any legwork to confirm or disprove that.  If it doesn't apply,
though, I'm leaning to the position that there's no reason to remove
array_nulls.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Remove array_nulls?

[Andres Freund]

On 2015-12-16 19:01:40 -0500, Robert Haas wrote:
> Yeah, there's something to be said for that, although to be honest in
> most cases I'd prefer to wait longer.   I wonder about perhaps
> planning to drop things after two lifecycles.

I don't really give a damn in this specific case. Seems to cost pretty
much nothing to continue having the GUC.

But I think in the more general case, which Tom seems to have brought up
as a point of policy, I think this is far to conservative. Yes, we owe
our users to not break their applications gratuitously. But we also owe
it to ourselves to keep development timeframes realistic, and not pay
overly much heed to people using seriously bad development and
maintenance practices.

It doesn't even benefit users really much delaying things that
long. Usually the migration costs, of fixing code previously kept
working by a GUC, increase over time, not decrease.


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Remove array_nulls?

[Robert Haas]

On Fri, Dec 18, 2015 at 12:02 PM, Andres Freund  wrote:
> On 2015-12-16 19:01:40 -0500, Robert Haas wrote:
>> Yeah, there's something to be said for that, although to be honest in
>> most cases I'd prefer to wait longer.   I wonder about perhaps
>> planning to drop things after two lifecycles.
>
> I don't really give a damn in this specific case. Seems to cost pretty
> much nothing to continue having the GUC.
>
> But I think in the more general case, which Tom seems to have brought up
> as a point of policy, I think this is far to conservative. Yes, we owe
> our users to not break their applications gratuitously. But we also owe
> it to ourselves to keep development timeframes realistic, and not pay
> overly much heed to people using seriously bad development and
> maintenance practices.

Well, Tom, Alvaro, and I all pretty much said that removing things
when it's blocking further development makes sense, but that there's
no hurry to remove anything else.  That sounds like what you are
saying, too.  So what's the actual disagreement here?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Remove array_nulls?

[David G. Johnston]

On Fri, Dec 18, 2015 at 10:25 AM, Tom Lane  wrote:

> Robert Haas  writes:
> > On Fri, Dec 18, 2015 at 12:10 PM, Andres Freund 
> 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.
>

​Hand-waving from me but I see a "positive reason" being that someone wants
to write and commit a patch that does not play nicely with the old
behavior.  That patch can then do away with giving the user an option as
long as the GUC itself was introduced in a now unsupported release.

I do not have a feel for how much grief having these GUCs in the code
causes but if the concern is for the end-user then simply removing them
from (or tucking them into a dark corner of) the documentation seems like
it would be the most useful means of "removing" while still be friendly to
users that just haven't wanted to update their application code to the new
way of doing things.

David J.

Re: [HACKERS] Remove array_nulls?

[Robert Haas]

On Fri, Dec 18, 2015 at 12:10 PM, Andres Freund  wrote:
> On 2015-12-18 12:06:43 -0500, Robert Haas wrote:
>> Well, Tom, Alvaro, and I all pretty much said that removing things
>> when it's blocking further development makes sense, but that there's
>> no hurry to remove anything else.  That sounds like what you are
>> saying, too.  So what's the actual disagreement here?
>
> 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.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Remove array_nulls?

[Robert Haas]

On Fri, Dec 18, 2015 at 12:19 PM, Joshua D. Drake  
wrote:
> On 12/18/2015 09:12 AM, Robert Haas wrote:
>>
>> On Fri, Dec 18, 2015 at 12:10 PM, Andres Freund 
>> wrote:
>>>
>>> On 2015-12-18 12:06:43 -0500, Robert Haas wrote:

 Well, Tom, Alvaro, and I all pretty much said that removing things
 when it's blocking further development makes sense, but that there's
 no hurry to remove anything else.  That sounds like what you are
 saying, too.  So what's the actual disagreement here?
>>>
>>>
>>> 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.
>
>
> Why not just keep it at the same rate as our support policy? The feature
> gets 5 years, then it is removed.

I did discuss that exact question in several previous postings to this thread...

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Remove array_nulls?

[Tom Lane]

Robert Haas  writes:
> On Fri, Dec 18, 2015 at 12:10 PM, Andres Freund  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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Remove array_nulls?

[Jim Nasby]

On 12/18/15 11:44 AM, Tom Lane wrote:

"David G. Johnston"  writes:

>On Fri, Dec 18, 2015 at 10:25 AM, Tom Lane  wrote:

>>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.

>​Hand-waving from me but I see a "positive reason" being that someone wants
>to write and commit a patch that does not play nicely with the old
>behavior.

Sure, that's also possible.  But no such patch is on the table now.


Someone (Tom?) mentioned upthread that if we wanted to do cleanup it 
should be more than just one GUC, and I agree with that, and I'm willing 
to investigate when the current compat GUCs went in and create a patch 
to remove the really old ones. My inclination would be to just do this 
as part of 10.0. (And I agree with Robert's comments about parallel 
being the most likely driver for bumping to 10.0).

--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Remove array_nulls?

[Robert Haas]

On Wed, Dec 16, 2015 at 10:48 PM, Jim Nasby  wrote:
> IIUC, that means supporting backwards compat. GUCs for 10 years, which seems
> a bit excessive. Granted, that's about the worse-case scenario for what I
> proposed (ie, we'd still be supporting 8.0 stuff right now).

Not to me.  GUCs like array_nulls don't really cost much - there is no
reason to be in a hurry about removing them that I can see.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Remove array_nulls?

[Robert Haas]

On Tue, Dec 15, 2015 at 1:26 AM, Michael Paquier
 wrote:
> On Tue, Dec 15, 2015 at 2:57 AM, Jim Nasby  wrote:
>> On 12/11/15 2:57 PM, Tom Lane wrote:
>>> Jim Nasby  writes:
>>> Perhaps, but I'd like to have a less ad-hoc process about it.  What's
>>> our policy for dropping backwards-compatibility GUCs?  Are there any
>>> others that should be removed now as well?
>>
>>
>> Perhaps it should be tied to bumping the major version number, which I'm
>> guessing would happen next whenever we get parallel query execution. If we
>> do that, a reasonable policy might be that a compatability GUC lives across
>> no more than 1 major version bump (ie, we wouldn't remove something in 9.0
>> that was added in 8.4).
>
> Another possibility may be to link that with the 5-year maintenance
> window of community: a compatibility GUC is dropped in the following
> major release if the oldest stable version maintained is the one that
> introduced it. Just an idea.

Yeah, there's something to be said for that, although to be honest in
most cases I'd prefer to wait longer.   I wonder about perhaps
planning to drop things after two lifecycles.  That is, when the
release where the incompatibility was added goes out of support, we
don't do anything, but when the release that was current when it went
out of support is itself out of support, then we drop the GUC.  For
example, 8.2 went EOL in December 2011, at which point the newest
release was 9.1.  So when 9.1 is out of support, then we could drop
it; that's due to happen this September.  So 9.6 (or 10.0, if we call
it that) could drop it.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Remove array_nulls?

[Jim Nasby]

On 12/16/15 6:01 PM, Robert Haas wrote:

On Tue, Dec 15, 2015 at 1:26 AM, Michael Paquier
 wrote:

On Tue, Dec 15, 2015 at 2:57 AM, Jim Nasby  wrote:

On 12/11/15 2:57 PM, Tom Lane wrote:

Jim Nasby  writes:
Perhaps, but I'd like to have a less ad-hoc process about it.  What's
our policy for dropping backwards-compatibility GUCs?  Are there any
others that should be removed now as well?



Perhaps it should be tied to bumping the major version number, which I'm
guessing would happen next whenever we get parallel query execution. If we
do that, a reasonable policy might be that a compatability GUC lives across
no more than 1 major version bump (ie, we wouldn't remove something in 9.0
that was added in 8.4).


Another possibility may be to link that with the 5-year maintenance
window of community: a compatibility GUC is dropped in the following
major release if the oldest stable version maintained is the one that
introduced it. Just an idea.


Yeah, there's something to be said for that, although to be honest in
most cases I'd prefer to wait longer.   I wonder about perhaps
planning to drop things after two lifecycles.  That is, when the
release where the incompatibility was added goes out of support, we
don't do anything, but when the release that was current when it went
out of support is itself out of support, then we drop the GUC.  For
example, 8.2 went EOL in December 2011, at which point the newest
release was 9.1.  So when 9.1 is out of support, then we could drop
it; that's due to happen this September.  So 9.6 (or 10.0, if we call
it that) could drop it.


IIUC, that means supporting backwards compat. GUCs for 10 years, which 
seems a bit excessive. Granted, that's about the worse-case scenario for 
what I proposed (ie, we'd still be supporting 8.0 stuff right now).


The reason I thought of tying it to "major major" release is just 
because those generate even more notice and attract more users than 
normal, so it'd be nice to clean house before doing one. Perhaps I'm 
just introducing complexity that there's no need for.


If we don't want to tie "major major" number, then I think we should 
just go with the normal support cycle.

--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Remove array_nulls?

[Michael Paquier]

On Tue, Dec 15, 2015 at 2:57 AM, Jim Nasby  wrote:
> On 12/11/15 2:57 PM, Tom Lane wrote:
>> Jim Nasby  writes:
>> Perhaps, but I'd like to have a less ad-hoc process about it.  What's
>> our policy for dropping backwards-compatibility GUCs?  Are there any
>> others that should be removed now as well?
>
>
> Perhaps it should be tied to bumping the major version number, which I'm
> guessing would happen next whenever we get parallel query execution. If we
> do that, a reasonable policy might be that a compatability GUC lives across
> no more than 1 major version bump (ie, we wouldn't remove something in 9.0
> that was added in 8.4).

Another possibility may be to link that with the 5-year maintenance
window of community: a compatibility GUC is dropped in the following
major release if the oldest stable version maintained is the one that
introduced it. Just an idea.
-- 
Michael


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Remove array_nulls?

[Jim Nasby]

On 12/11/15 2:57 PM, Tom Lane wrote:

Jim Nasby  writes:

A quick doc search indicates this config was created in 9.0, though the
docs state it's for a change that happened in 8.2[1].


Don't know what you're looking at, but the GUC is definitely there (and
documented) in 8.2.


Is it time to remove this GUC?


Perhaps, but I'd like to have a less ad-hoc process about it.  What's
our policy for dropping backwards-compatibility GUCs?  Are there any
others that should be removed now as well?


Perhaps it should be tied to bumping the major version number, which I'm 
guessing would happen next whenever we get parallel query execution. If 
we do that, a reasonable policy might be that a compatability GUC lives 
across no more than 1 major version bump (ie, we wouldn't remove 
something in 9.0 that was added in 8.4).

--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Remove array_nulls?

[Tom Lane]

Jim Nasby  writes:
> A quick doc search indicates this config was created in 9.0, though the 
> docs state it's for a change that happened in 8.2[1].

Don't know what you're looking at, but the GUC is definitely there (and
documented) in 8.2.

> Is it time to remove this GUC?

Perhaps, but I'd like to have a less ad-hoc process about it.  What's
our policy for dropping backwards-compatibility GUCs?  Are there any
others that should be removed now as well?

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers