Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()
Дата
Msg-id 23797.1494558638@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()  (Neha Khatri <nehakhatri5@gmail.com>)
Список pgsql-hackers
Neha Khatri <nehakhatri5@gmail.com> writes:
> On Fri, May 12, 2017 at 12:56 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Neha Khatri <nehakhatri5@gmail.com> writes:
>>> Following are pg_controldata interfaces that might require change:
>>> Latest checkpoint location:
>>> Prior checkpoint location:
>>> Latest checkpoint's REDO location:
>>> Minimum recovery ending location:
>>> Backup start location:
>>> Backup end location:

>> My inclination is to leave these messages alone.  They're not really
>> inconsistent with anything.  Where we seem to be ending up is that
>> "lsn" will be used in things like function and column names, but
>> documentation will continue to spell out phrases like "WAL location".

> Are you indicating that the above phrases do not require change because
> those are consistent with other references. Or the other thread [1]
> (renaming 'transaction log') should take care of it.

Personally I'm happy to leave those particular messages as they are.
Yes, a case could be made for changing them to say "LSN", and a different
case could be made for changing them to say "WAL location", but I don't
think either of those are real improvements.  Also, this'd be propagating
the compatibility problem into yet a new place, because there are surely
user-written scripts out there that grep the output for exactly these
spellings.

It's a judgment call though, and others might have different opinions.
        regards, tom lane



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

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: [HACKERS] UPDATE of partition key
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] multi-column range partition constraint