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

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()
Дата
Msg-id CA+TgmoZjDo9ckxf6aYrqyMoiSw5yfBB2gpMbrBtE9zr==uczhw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] Should pg_current_wal_location() becomepg_current_wal_lsn()
Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()
Список pgsql-hackers
On Fri, Apr 14, 2017 at 6:52 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
>> If we're talking about making things easier to understand, wouldn't a
>> random user rather know what a WAL "location" is instead of a WAL "LSN"?
>
> I wouldn't object to standardizing on "location" instead of "lsn" in the
> related function and column names.  What I don't like is using different
> words for the same thing.

The case mentioned in the subject of this thread has been using the
word "location" since time immemorial.  It's true that we've already
renamed it (xlog -> wal) in this release, so if we want to standardize
on lsn, now's certainly the time to do it.  I'm worried that
pg_current_wal_lsn() is an identifier composed almost entirely of
abbreviations and therefore possibly just as impenetrable as
qx_current_pfq_dnr(), but maybe we should assume that LSN is a term of
art with which knowledgeable users are required to be familiar, much
as we are doing for "WAL".

It appears, from grepping the 9.6 version of pg_proc.h, that both lsn
and location have some historical precedent.

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



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

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: [HACKERS] Cutting initdb's runtime (Perl question embedded)
Следующее
От: Greg Stark
Дата:
Сообщение: Re: [HACKERS] Some thoughts about SCRAM implementation