Anastasia Lubennikova <a.lubennikova@postgrespro.ru> writes:
> [ return_heaptuple_in_btree_indexonlyscan_v2.patch ]
I took a quick look at this, but I'm concerned about a couple of points:
1. What's the performance penalty of forming (and then deforming) the
added heap tuple? We'd be paying it for every index-only scan, whether
or not any CURRENT OF fetch ever happened.
2. The constructed tuple provides tableoid and ctid all right, but it'd
still have garbage values for other system columns. As the code stands,
we will properly error out if some attempt is made to fetch any of those
other columns, but with this change we'd just return the garbage. This
is a minor point, but it doesn't seem negligible to me; it might've been
hard to identify the bug at hand if we'd not had the cross-check of not
building a heap tuple.
At this point Yugo-san's original patch is starting to look more
attractive. It's still ugly, but at least it's not imposing a performance
cost on unrelated queries.
regards, tom lane
