Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn() - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()
Date
Msg-id CA+TgmoZjDo9ckxf6aYrqyMoiSw5yfBB2gpMbrBtE9zr==uczhw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Should pg_current_wal_location() becomepg_current_wal_lsn()  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()  (David Steele <david@pgmasters.net>)
List 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 by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: [HACKERS] Cutting initdb's runtime (Perl question embedded)
Next
From: Greg Stark
Date:
Subject: Re: [HACKERS] Some thoughts about SCRAM implementation