Re: Should pg_current_wal_location() become pg_current_wal_lsn()

On Fri, Apr 14, 2017 at 10:22:36AM -0400, Tom Lane 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.

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

--
Bruce Momjian <bruce(at)momjian(dot)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 +