* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost <sfr...@snowman.net> writes: > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > >> It's not a "half measure", it's providing a sane upgrade path. > > > I really don't see it that way. We're talking about existing scripts > > which will break if the binary is renamed. That means that, today, > > they're using createlang/createdb/createuser. The options for a user > > using such a script with the proposed approach, when PG10 comes out > > are: > > > 1) don't change the script, because the old names work > > 2) adjust the script to work with both X and pg_X values > > You're neglecting what I think most people would want to do: > > 3) Wait till they no longer care about supporting versions that have > only the old names, then change their scripts to use pg_X.
Perhaps it's a bit stark, but my experience has been that people tend to fall into one of the two camps I outlined above. If we take your approach to its logical conclustion then we should be planning to maintain all user-facing deprecated features for as long as there is a version where it exists in a non-deprecated fashion, in other words for 5 years, if we assume that script authors only care about supporting as far back as we do, which I'm not entirely sure is a great assumption to begin with, but I'd say it's at least a minimum. To that I say: heck no. I understand that there has been grief due to the various user-facing changes we've made recently and I completely understand those complaints because it means that developers have to deal with version-specific differences, particularly when it comes to monitoring and now with the pg_xlog -> pg_wal changes, more with backup too, but trying to deal with multiple sets of interfaces over a long period of time is going to be incredibly painful and very confusing for users, especially new users. In some cases, we would end up with 5 interfaces, all having to be maintained across all of the back-branches, because we changed something in every release, deprecating each prior version as we went. No, I don't feel that this kind of backwards-compatibility is really something we want, as a project. We, for very good reason, support 5 years worth of back-branches to allow users the opportunity and time to migrate at a reasoned pace, possibly even skipping versions as they go if they don't wish to make changes every year. I'll admit that this is a bit of a straw-man and goes beyond what you're suggesting here, specifically, but that just begs the question of "where do we draw the line", if we are going to draw one. Are scripts which use command-line utilities more of an issue to break than those which query pg_stat_activity? > > I anticipate an argument along the lines of "but we're giving them time > > to make the change" but I don't see that as really holding all that much > > weight either- we maintain back-branch releases for years to give users > > time to adjust to changes that have been made in the latest releases. > > Yes, and that also means that other tooling has to be prepared to work > with multiple releases. You're proposing to make that harder, and I > do not think there's sufficient reason. I do think, in the general sense, that tools based on PG should be prepared to deal with differences between major versions, because we have quite a few of those. I'm hard-pressed to come up with a major PG tool which *doesn't* have mechanisms for dealing with differences between major versions already. There's certainly no shortage of PG-based applications which also have code for dealing with different PG major versions either. > This line of argument means that we probably couldn't remove the old > names until 9.6 is out of support, but so what? We had the deprecation > notice for createlang in place since 9.1, and I think that that's about > the right timeline for this sort of changeover. We should not > cavalierly break peoples' scripts for what's fundamentally just a > cosmetic improvement. Per my question above- when is 5 years of deprecated-but-working support for a feature the right timeline and when isn't it? My feeling is that most of the changes we make in this regard are accepted under the "well, it's a major version change, so you'll need to adjust" but this change isn't viewed in that same light and I'm not really sure that I see a good reason for that. I'll admit that part of that is likely because I don't think I have *ever* used createdb or createlang or createuser (excepting whatever regression tests run them), but even so, figuring out some idea where we draw this line between things that need to be deprecated for 5 years and things that don't would be useful, though likely a source of ongoing discussion too. > (Or in other words, we've been getting along fine with these script names > for circa twenty years, so what's the rush to change them RIGHT NOW?) To be clear, I'm not in any particular rush to change them 'RIGHT NOW'. I tend to agree with Magnus that we're doing a lot of other things in PG10 and that makes it a bit of a natural point, but I don't hold that position terribly strongly. On the other hand, I do not relish the idea of providing backwards-compatibility for every user-facing change we do for 5 years and that's where I feel this approach is encouraging us to go. Thanks! Stephen
Description: Digital signature