Re: Should pg_current_wal_location() become pg_current_wal_lsn()

* Tom Lane (tgl@sss.pgh.pa.us) 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.

I agree and definitely view 'lsn' as better than just 'location' when
we're talking about an lsn.  The datatype is 'pg_lsn', let's use 'lsn'
whenever that's what it is.  Consistency here is really good.

Thanks!

Stephen