On Fri, Apr 26, 2019 at 5:13 PM Peter Geoghegan <p...@bowt.ie> wrote: > On Fri, Apr 26, 2019 at 5:05 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Yeah, I'd be fine with that, although the disconnect between the type > > name and the comment terminology might confuse some people. > > Maybe, but the fact that the ItemIdData struct consists of bit fields > that are all named "lp_*" offers a hint. Plus you have the LP_* > constants that get stored in ItemIdData.lp_flags.
Attached draft patch adjusts code comments and error messages where a line pointer is referred to as an item pointer. It turns out that this practice isn't all that prevalent. Here are some specific concerns that I had to think about when writing the patch, though: * I ended up removing a big indexam.c "old comments" comment paragraph from the Berkeley days, because it used the term item pointer in what seemed like the wrong way, but also because AFAICT it's totally obsolete. * Someone should confirm that I have preserved the original intent of the changes within README.HOT, and the heapam changes that relate to pruning. It's possible that I changed "item pointer" to "line pointer" in one or two places where I should have changed "item pointer" to "tuple" instead. * I changed a few long standing "can't happen" error messages that concern corruption, most of which also relate to pruning. Maybe that's a cost that needs to be considered. * I changed a lazy_scan_heap() log message of long-standing. Another downside that needs to be considered. * I expanded a little on the advantages of using line pointers within bufpage.h. That seemed in scope to me, because it drives home the distinction between item pointers and line pointers. -- Peter Geoghegan
v1-0001-Standardize-line-pointers-item-pointer-terminolog.patch
Description: Binary data