Re: Should pg_current_wal_location() become pg_current_wal_lsn()

From: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
To: robertmhaas(at)gmail(dot)com
Cc: tgl(at)sss(dot)pgh(dot)pa(dot)us, peter(dot)eisentraut(at)2ndquadrant(dot)com, bruce(at)momjian(dot)us, david(dot)rowley(at)2ndquadrant(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Should pg_current_wal_location() become pg_current_wal_lsn()
Date: 2017-04-17 05:54:52
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

At Sat, 15 Apr 2017 12:56:32 -0400, Robert Haas <robertmhaas(at)gmail(dot)com> wrote in <CA+TgmoZjDo9ckxf6aYrqyMoiSw5yfBB2gpMbrBtE9zr==uczhw(at)mail(dot)gmail(dot)com>
> On Fri, Apr 14, 2017 at 6:52 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)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.

I'd better to have replied here. The detail is in my reply on
another brandh of this thread.

After all, "location" seems better to me in user interface. We
could rename almost all of %lsn% names into %location% except
pg_lsn oprators as long as it doesn't become too long or complex.

One annoyance is the historical function pg_xlog_location_diff(),
which is currently just an alias of pg_lsn_mi. It is
substantially an operator, but 'pg_wal_lsn_diff()' is so far from
the historical name that it becomes totally useless.


Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2017-04-17 06:00:31 Re: Shouldn't duplicate addition to publication be a no-op?
Previous Message Fabien COELHO 2017-04-17 05:51:45 pgbench tap tests & minor fixes