Thread: Remove array_nulls?
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]. Both versions are now supported, and 8.2 is obviously ancient. Is it time to remove this GUC? [1] http://www.postgresql.org/docs/9.0/static/runtime-config-compatible.html -- 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
Jim Nasby <Jim.Nasby@BlueTreble.com> 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
On 12/11/15 2:57 PM, Tom Lane wrote: > Jim Nasby <Jim.Nasby@BlueTreble.com> 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
On Tue, Dec 15, 2015 at 2:57 AM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote: > On 12/11/15 2:57 PM, Tom Lane wrote: >> Jim Nasby <Jim.Nasby@BlueTreble.com> 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
On Tue, Dec 15, 2015 at 1:26 AM, Michael Paquier <michael.paquier@gmail.com> wrote: > On Tue, Dec 15, 2015 at 2:57 AM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote: >> On 12/11/15 2:57 PM, Tom Lane wrote: >>> Jim Nasby <Jim.Nasby@BlueTreble.com> 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
On 12/16/15 6:01 PM, Robert Haas wrote: > On Tue, Dec 15, 2015 at 1:26 AM, Michael Paquier > <michael.paquier@gmail.com> wrote: >> On Tue, Dec 15, 2015 at 2:57 AM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote: >>> On 12/11/15 2:57 PM, Tom Lane wrote: >>>> Jim Nasby <Jim.Nasby@BlueTreble.com> 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
On Wed, Dec 16, 2015 at 10:48 PM, Jim Nasby <Jim.Nasby@bluetreble.com> 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
On Thu, Dec 17, 2015 at 4:31 PM, Robert Haas <robertmhaas@gmail.com> wrote: > On Wed, Dec 16, 2015 at 10:48 PM, Jim Nasby <Jim.Nasby@bluetreble.com> 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
On Fri, Dec 18, 2015 at 9:52 AM, Robert Treat <rob@xzilla.net> wrote: > On Thu, Dec 17, 2015 at 4:31 PM, Robert Haas <robertmhaas@gmail.com> wrote: >> On Wed, Dec 16, 2015 at 10:48 PM, Jim Nasby <Jim.Nasby@bluetreble.com> 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
Robert Haas wrote: > On Fri, Dec 18, 2015 at 9:52 AM, Robert Treat <rob@xzilla.net> 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 Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Fri, Dec 18, 2015 at 11:08 AM, Alvaro Herrera <alvherre@2ndquadrant.com> 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
Robert Haas <robertmhaas@gmail.com> 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 <tgl@sss.pgh.pa.us>
Date: Wed Oct 21 20:38:58 2009 +0000
Remove regex_flavor GUC, so that regular expressions are always "advanced" style by default. Per discussion,
thereseems to be hardly anything that really relies on being able to change the regex flavor, so the ability to
selectit via embedded options ought to be enough for any stragglers. Also, if we didn't remove the GUC, we'd really
bemorally obligated to mark the regex functions non-immutable, which'd possibly create performance issues.
commit 289e2905c82fc37f8b82b088bb823742aad4bb68
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date: Wed Oct 21 20:22:38 2009 +0000
Remove add_missing_from GUC and associated parser support for "implicit RTEs". Per recent discussion,
add_missing_fromhas been deprecated for long enough to consider removing, and it's getting in the way of planned
parserrefactoring. 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
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.
On Fri, Dec 18, 2015 at 12:02 PM, Andres Freund <andres@anarazel.de> 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
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.
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
On Fri, Dec 18, 2015 at 12:10 PM, Andres Freund <andres@anarazel.de> 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
On 12/18/2015 09:12 AM, Robert Haas wrote: > On Fri, Dec 18, 2015 at 12:10 PM, Andres Freund <andres@anarazel.de> 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.
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
On Fri, Dec 18, 2015 at 12:19 PM, Joshua D. Drake <jd@commandprompt.com> wrote: > On 12/18/2015 09:12 AM, Robert Haas wrote: >> >> On Fri, Dec 18, 2015 at 12:10 PM, Andres Freund <andres@anarazel.de> >> 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
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.
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.
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Fri, Dec 18, 2015 at 10:25 AM, Tom Lane <tgl@sss.pgh.pa.us> 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
On 12/18/15 11:44 AM, Tom Lane wrote: > "David G. Johnston"<david.g.johnston@gmail.com> writes: >> >On Fri, Dec 18, 2015 at 10:25 AM, Tom Lane<tgl@sss.pgh.pa.us> 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