Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal - Mailing list pgsql-hackers

Andres,

* Andres Freund (andres@anarazel.de) wrote:
> On 2017-01-03 10:37:08 -0500, Stephen Frost wrote:
> > * Vladimir Rusinov (vrusinov@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.

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

As I said in what you did quote above- I won't complain if someone wants
the aliases and we include them in the documentation, but I don't agree
with the other suggestions of having undocumented aliases or not making
the change.

Thanks!

Stephen