On 19 April 2017 at 03:33, David Steele <david@pgmasters.net> wrote:
> +1, and I'm in favor of using "lsn" wherever applicable. It seems to me
> that if a user calls a function (or queries a table) that returns an lsn
> then they should be aware of what an lsn is.
OK, so I've read over this thread again and I think it's time to
summarise the votes:
It seem that;
Robert mentions he'd be inclined not to tinker with this, but mentions
nothing of inconsistency.
Bruce mentions he'd like consistency but does not mention which he'd prefer.
Stephen wants consistency and votes to change "location" to "lsn" in
regards to a pg_lsn.
Peter would rather see use of "location", mentions about changing the
new in v10 stuff, but not about the existing 9.6 usages of lsn in
column names
Tom would not object to use of "location" over "lsn".
Kyotaro would rather see the use of "location" for all apart from the
pg_lsn operator functions. Unsure how we handle pg_wal_location_diff()
David Steel would rather see this changed to use "lsn" instead of location.
So in summary, nobody apart from Robert appeared to have any concerns
over breaking backward compatibility.
In favour of "location" -> "lsn": Stephen, David Steel,
In favour of "lsn" -> "location": Peter, Tom, Kyotaro
I left Bruce out since he just voted for consistency.
So "lsn" -> "location" seems to be winning
Is that enough to proceed?
Anyone else?
The patch to do this should likely also include a regression test to
ensure nothing new creeps in which breaks the new standard.
-- David Rowley http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
