On Fri, Apr 14, 2017 at 10:22:36AM -0400, Tom Lane 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.
Yeah, this area is complex enough so any consistency we can add helps. -- Bruce Momjian <br...@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 + -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers