Re: Should pg_current_wal_location() become pg_current_wal_lsn()

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > On Fri, Apr 14, 2017 at 4:28 AM, Kyotaro HORIGUCHI
> > <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)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