On Wed, Jan 4, 2017 at 4:32 PM, Andres Freund <and...@anarazel.de> wrote: > Hi, > > 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? > > >> 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.
+1 Regards, -- Fujii Masao -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
