On 2017-01-04 09:38:42 -0500, Stephen Frost wrote: > Andres, > > * Andres Freund (and...@anarazel.de) wrote: > > On 2017-01-03 10:37:08 -0500, Stephen Frost wrote: > > > * Vladimir Rusinov (vrusi...@google.com) wrote: > > > > I think I +1 on this. > > > > I've did a github search on these function names and there is a lot of > > > > code > > > > that use them. E.g. there is 8.5k hits for pg_last_xlog_location > > > > <https://github.com/search?q=pg_last_xlog_replay_location&type=Code&utf8=%E2%9C%93>; > > > > a lot of them a forks and copy-pastes, but still, that's quite a lot. > > > > Let's > > > > keep the aliases around for couple of versions after which hopefully a > > > > lot > > > > of the code will be updated. > > > > > > And there's 12k hits for pg_xlog. > > > > > If we do that, we'll just end up with exactly the same question about > > > removing them and the same amount of code breakage in a few years. I > > > don't see how that is really helping anyone. > > > > Meh^2. The cost of having pg_xlog was that people lost their > > data. Hence their was motivation of changing things. The cost of having > > some function aliases is, what, a pg_proc line? If we end up carrying > > them forever, so what? > > I outlined exactly that in the part you didn't quote.
Sure, but my point was that you and several others essentially argue for breaking things gratuitously. And I think that's bad. That you can live with backward compatibility doesn't change that point. > > > If we really feel that this is the only thing between 9.6 and 10 that'll > > > cause problems for some serious amount of code and we don't expect to > > > change the function APIs anytime in the near future then perhaps we > > > could keep aliases, *document* them, and treat them as full functions > > > just like the regular ones. > > > > I think we've been far to cavalier lately about unnecessarily breaking > > admin and monitoring tools. There's been pg_stat_activity backward > > incompat changes in most of the last releases. It's a *PAIN* to develop > > monitoring / admin tools that work with a number of releases. It's fine > > to cause that pain if there's some considerable benefit (e.g. not > > triggering data loss seems like a case for that, as imo is unifying > > configuration), but I don't see how that justifying breaking things > > gratuitously. Just renaming well known functions for a minor bit of > > cleanliness seems not to survive a cost/benefit analysis. > > I agree that we have been breaking monitoring tools on the regular for a > while as we continue to add capabilities and improve things, which is > part of the reason that I don't see this particular break as a very big > deal- serious monitoring tools are going to need to be updated anyway. I have no problem with breaking things when necessary. I do have a problem when we do so willy-nilly when providing backward-compatibility would have been easy enough. E.g. Nearly all recent pg_stat_activity changes would have been doable just as well without breakage. > I don't see that changing any time soon either- we are woefully far > behind in this area compared to other databases and we should be trying > to encourage people to continue improving these areas, not making things > unnecessairly difficult by requiring backwards compatibility hacks. By breaking stuff on a regular basis we're also showing that we're behind. Compatibility also is a big topic. We also force users to stay behind longer, and to upgrade less frequently. Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
