Re: [PATCH] Rename pg_switch_xlog to pg_switch_wal

On Thu, Jan 12, 2017 at 8:56 AM, David Steele <david(at)pgmasters(dot)net> wrote:
>> So, to sum up things on this thread, here are the votes about the use
>> of aliases or a pure breakage:
>> - No to aliases, shake the world: Stephen, Tom, David F, Vik, Bruce M => 5
>> - Yes to aliases: Michael P, Andres, Peter E., Cynthia S, Jim N,
>> Vladimir, Simon R, Fujii-san => 8
>> If I misunderstood things, please feel free to speak up.
>
> I'm also in the "no to aliases" camp.

Me too.

I appreciate what people are saying about the pain that is involved
when we change administration interfaces. However, I suspect that
most of that pain falls on tool authors, who are disproportionately
represented in this forum, and on DBAs, who may not like it much but
can probably cope with it. It's not really going to affect
applications, because applications generally don't care about the
transaction log directly. What is really bad is when we break syntax
that might be used in queries, or in PL/pgsql functions. That's why
the 8.3 casting changes were so painful, and why the discussion about
changing PL/pgsql semantics is so dominated by people who don't want
to break what's worth now. When we change things in those areas,
people who know nothing and care nothing about PostgreSQL other than
that it's the underlying database have to update their SQL, and that
hurts adoption. Anyone who is affected by these proposed changes is
already deeply invested in PostgreSQL.

Also, I think it is absolutely wrong to suppose that there's no pain
involved in having these aliases around forever. I thought the idea
of stuffing the aliases in a contrib module was a rather good one,
actually, because then the people who need them can install them
easily and yet the burden on core to maintain them is largely removed.
Also, there's still positive pressure for tools that haven't been
updated to get themselves updated to work without that compatibility
extension, so eventually the need for it should go away. I have not
abandoned all hope of eventually removing contrib/tsearch2 from the
core distribution. When we keep things in the core system catalogs,
they just accumulate forever. There will not only be old code that
continues to use the old names; there will be new code that uses the
old names. There will be people who ask why we have two copies of the
function, or aren't sure which one to use. Somebody will have a
tab-completion fail that results from an irrelevant decision between
two names for the same thing. Individually, these things don't matter
very much, but over time they lead to a user experience that's full of
warts and a developer experience that is enslaved to historical
garbage that takes time and energy away from new feature development.

So, my order of preference is:

1. Rename everything and add an extension to create aliases for the old names.
2. Rename everything without adding a backward-compatibility extension.
3. Don't rename anything.
4. Stomach flu.
5. Put a second name for everything in pg_proc.h.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company