Re: Should pg_current_wal_location() become pg_current_wal_lsn()

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, david(dot)rowley(at)2ndquadrant(dot)com
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Should pg_current_wal_location() become pg_current_wal_lsn()
Date: 2017-04-14 22:26:37
Message-ID: 052f4ce0-159a-1666-f136-91977d3267a5@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 4/14/17 04:28, Kyotaro HORIGUCHI wrote:
> =# select distinct attname from pg_attribute where attname like '%lsn%';
> attname
> ---------------------
> confirmed_flush_lsn
> latest_end_lsn
> local_lsn
> receive_start_lsn
> received_lsn
> remote_lsn
> restart_lsn
> srsublsn
> (8 rows)
>
>
> Feature is already frozen, but this seems inconsistent a bit..

I think these are all recently added for logical replication. We could
rename them to _location.

I'm not a fan of renaming everything the opposite way.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jaime Casanova 2017-04-14 22:26:45 minor typo in client-auth.sgml
Previous Message Tom Lane 2017-04-14 21:54:19 Re: Cutting initdb's runtime (Perl question embedded)