Re: [PATCH] Rename pg_switch_xlog to pg_switch_wal

On Wed, Jan 4, 2017 at 4:32 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> Hi,
>
> On 2017-01-03 10:37:08 -0500, Stephen Frost wrote:
>> * Vladimir Rusinov (vrusinov(at)google(dot)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