Re: [PATCH] Rename pg_switch_xlog to pg_switch_wal

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Vladimir Rusinov <vrusinov(at)google(dot)com>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, David Steele <david(at)pgmasters(dot)net>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Cynthia Shang <cynthia(dot)shang(at)crunchydata(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Rename pg_switch_xlog to pg_switch_wal
Date: 2017-01-03 16:34:50
Message-ID: 20170103163450.GE18360@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Vladimir Rusinov (vrusinov(at)google(dot)com) wrote:
> On Tue, Jan 3, 2017 at 3:37 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > If they're maintained, then they'll be updated. I don't have any
> >
> sympathy if they aren't maintained.
> >
>
> Updating may be non-trivial effort even if they are maintained. E.g. some
> project may need to support both 9.6 and 10.0, and a lot of them written in
> a way that makes conditionals on function names non-trivial (e.g. there's
> just flat .sql file that is expected to work everywhere).

I don't think we should be concerned with that. Anything but the
simplest SQL scripts have a good chance of being broken across major
version upgrades, *especially* ones that are using admin functions,
which we change on a regular basis for various reasons.

> *document* them, and treat them as full functions just like the regular
> > ones.
>
> In my next WIP version of the patch (
> https://github.com/vrusinov/postgres/tree/rename-xlog) I keep references to
> old names in the description for the new names. This makes it
> searchable/greppable and does not encourage their usage. Exact format may
> change, but I'd certainly not like to treat them exactly like full
> functions and I'd like them to be mentioned so it's possible to search.

My point is that we need to document them and make sure to mention them
whenever we change anything about them (release notes, etc), exactly to
make sure that someone reading the release notes will know what to
search their code for.

> Overall, I don't feel super-strong either way. Adding aliases does not seem
> like a lot of effort or burden and I also see arguments for dropping them
> sooner than later. As a compromise I propose keep aliases with hard
> deadline for removal in 11.0.

Ugh, no, I don't want to have this argument again next year.

> This way we are nicer to people who maintain their tools and read release
> notes via giving them more time, and nicer to ourselves via cleaning legacy
> stuff relatively soon.

They have plenty of time. If we're going to remove them, then let's
just do it and have a clean break.

Thanks!

Stephen

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2017-01-03 16:35:35 Re: Broken atomics code on PPC with FreeBSD 10.3
Previous Message Fabien COELHO 2017-01-03 16:33:25 Re: proposal: session server side variables