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 +