Re: Should pg_current_wal_location() become pg_current_wal_lsn()

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: David Steele <david@pgmasters.net>
Cc: Stephen Frost <sfrost@snowman.net>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, David Rowley <david.rowley@2ndquadrant.com>, Euler Taveira <euler@timbira.com.br>, Michael Paquier <michael.paquier@gmail.com>, Robert Haas <robertmhaas@gmail.com>, Bruce Momjian <bruce@momjian.us>, Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2017-05-10T17:13:59Z
Lists: pgsql-hackers
David Steele <david@pgmasters.net> writes:
> If I read this correctly, we won't change the names of any functions 
> that we haven't *already* changed the names of, and only one view would 
> be changed to bring it into line with the rest.

I have now looked through the patch more carefully, and noted some changes
I forgot to account for in my previous summary: it also renames some
function arguments and output columns, which previously were variously
"location", "wal_position", etc.  I'd missed that for functions that don't
have a formal view in front of them.  This affects

pg_control_checkpoint
pg_control_recovery
pg_create_logical_replication_slot
pg_create_physical_replication_slot
pg_logical_slot_get_binary_changes
pg_logical_slot_get_changes
pg_logical_slot_peek_binary_changes
pg_logical_slot_peek_changes

So that's an additional source of possible compatibility breaks.
It doesn't seem like enough to change anybody's vote on the issue,
but I mention it for completeness.

In terms of the alternatives I listed previously, it seems like
nobody liked alternatives #3, #4, or #5, leaving us with #1 (do
nothing) or #2 (apply this patch).  By my count, Peter is the
only one in favor of doing nothing, and is outvoted.  I'll push
the patch later today if I don't hear additional comments.

			regards, tom lane


Commits

  1. Rename WAL-related functions and views to use "lsn" not "location".