* Tom Lane (t...@sss.pgh.pa.us) wrote: > Robert Haas <robertmh...@gmail.com> writes: > > On Fri, Apr 14, 2017 at 4:28 AM, Kyotaro HORIGUCHI > > <horiguchi.kyot...@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
signature.asc
Description: Digital signature
