Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

Поиск
Список
Период
Сортировка
От Josh Berkus
Тема Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal
Дата
Msg-id c18030f8-0601-bde3-62a4-d1da707ba068@berkus.org
обсуждение исходный текст
Ответ на Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal  (Stephen Frost <sfrost@snowman.net>)
Список pgsql-hackers
On 02/09/2017 12:42 PM, Stephen Frost wrote:
> * Josh Berkus (josh@berkus.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.

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.

-- 
Josh Berkus
Containers & Databases Oh My!



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)