Re: [PATCH] Rename pg_switch_xlog to pg_switch_wal

On 02/09/2017 12:53 PM, Stephen Frost wrote:
> * Josh Berkus (josh(at)berkus(dot)org) wrote:
>> On 02/09/2017 12:42 PM, Stephen Frost wrote:
>>> * Josh Berkus (josh(at)berkus(dot)org) wrote:
>>>> On 02/09/2017 11:08 AM, Tom Lane wrote:
>>>>> Agreed, let's just get it done.
>>>>>
>>>>> Although this doesn't really settle whether we ought to do 3a (with
>>>>> backwards-compatibility function aliases in core) or 3b (without 'em).
>>>>> Do people want to re-vote, understanding that those are the remaining
>>>>> choices?
>>>>
>>>> Does 3a) mean keeping the aliases more-or-less forever?
>>>>
>>>> If not, I vote for 3b. If we're going to need to break stuff, let's
>>>> just do it.
>>>>
>>>> If we can keep the aliases for 6-10 years, then I see no reason not to
>>>> have them (3a). They're not exactly likely to conflict with user-chosen
>>>> names.
>>>
>>> When we remove pg_shadow, then I'll be willing to agree that maybe we
>>> can start having things in PG for a couple releases that are just for
>>> backwards-compatibility and will actually be removed later.
>>>
>>> History has shown that's next to impossible, however.
>>
>> That's why I said 6-10 years. If we're doing 3a, realistically we're
>> supporting it until PostgreSQL 16, at least, and more likely 20. I'm OK
>> with that.
>
> Uh, to be clear, I think it's an entirely bad thing that we've had those
> views and various other cruft hang around for over 10 years.
>
> And removing them today will probably still have people crying about how
> pgAdmin3 and other things still use them.
>
>> What I'm voting against is the idea that we'll have aliases in core, but
>> remove them in two releases. Either that's unrealistic, or it's just
>> prolonging the pain.
>
> Waiting 10+ years doesn't make the pain go away when it comes to
> removing things like that.

Sure it does. That's two whole generations of client tools. For
example, at that point, pgAdmin3 won't reliably run on any supported
platform, so it won't be a problem if we break it.

If we clearly mark the old function names as deprecated aliases, client
tools will gradually move to the new names.

Counter-argument: moving the directory is going to break many tools
anyway, so why bother with function aliases?

--
Josh Berkus
Containers & Databases Oh My!