On 19 April 2017 at 03:33, David Steele <da...@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 -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers