Re: Should pg_current_wal_location() become pg_current_wal_lsn()

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Steele <david(at)pgmasters(dot)net>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Euler Taveira <euler(at)timbira(dot)com(dot)br>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Should pg_current_wal_location() become pg_current_wal_lsn()
Date: 2017-05-10 17:13:59
Message-ID: 27595.1494436439@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

David Steele <david(at)pgmasters(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2017-05-10 17:28:39 Re: [HACKERS] Concurrent ALTER SEQUENCE RESTART Regression
Previous Message Robert Haas 2017-05-10 16:43:20 Re: [POC] hash partitioning