Re: [HACKERS] Should pg_current_wal_location() becomepg_current_wal_lsn()

On Fri, Apr 14, 2017 at 10:22:36AM -0400, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > On Fri, Apr 14, 2017 at 4:28 AM, Kyotaro HORIGUCHI
> > <horiguchi.kyotaro@lab.ntt.co.jp> wrote:
> >> Similariliy, these columns may need renaming.
> 
> > Personally, I would be inclined not to tinker with this, not just
> > because we're after freeze but because it doesn't seem like an
> > improvement to me.  Referring to an LSN as  location seems fine to me;
> > I mean, granted, it's one specific kind of location, but that doesn't
> > make it wrong.
> 
> In a green field it would be perfectly fine --- but I think Kyotaro-san's
> point is about consistency.  If all the other exposed names that involve
> the same concept use "lsn", then it's fair to say that it's a bad idea
> for these four column names to be randomly different from the rest.
> 
> Now this is a pre-existing problem: those column names existed in 9.6,
> and so did some of the ones named using "lsn".  But we've added more
> of the latter in v10.  I think the real problem right now is that nobody
> has a rule to follow about which way to name new exposed references to
> the concept, and that's simply bad.
> 
> It's possible that we should say that backwards compatibility outweighs
> consistency and therefore it's too late to change these names.  But
> I think your argument above is missing the point.

Yeah, this area is complex enough so any consistency we can add helps.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +