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 по дате отправления: