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

From Robert Haas
Subject Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()
Date
Msg-id CA+TgmoYMLQu0hSckDRtK4+yOp0GRez0G0ZAGanF2gLm8YAPEMg@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, May 10, 2017 at 1:13 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.

For the record, I also voted for doing nothing.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] [POC] hash partitioning
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] Adding support for Default partition in partitioning