Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn() |
Дата | |
Msg-id | 27595.1494436439@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Should pg_current_wal_location() becomepg_current_wal_lsn() (David Steele <david@pgmasters.net>) |
Ответы |
Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()
|
Список | 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
В списке pgsql-hackers по дате отправления: