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

From Peter Eisentraut
Subject Re: [HACKERS] Should pg_current_wal_location() becomepg_current_wal_lsn()
Date
Msg-id 052f4ce0-159a-1666-f136-91977d3267a5@2ndquadrant.com
Whole thread Raw
In response to Re: [HACKERS] Should pg_current_wal_location() becomepg_current_wal_lsn()  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Responses Re: [HACKERS] Should pg_current_wal_location() becomepg_current_wal_lsn()  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
List 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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Cutting initdb's runtime (Perl question embedded)
Next
From: Jaime Casanova
Date:
Subject: [HACKERS] minor typo in client-auth.sgml