Martijn van Oosterhout <kleptog@svana.org> writes:
> On Mon, Jan 16, 2006 at 12:07:44PM -0500, Tom Lane wrote:
>> Since you didn't understand what I was saying, I suspect that plan A is
>> too confusing ...
> Umm, yeah. Now you've explained it I think it should be excluded on the
> basis that it'll be a source of bugs. For all the places that matter a
> row-condition needs to be treated as a whole and storing parts in a
> top level ScanKey array just seems like asking for trouble.
Actually, I'd just been coming back to plan A, after realizing that it's
not possible to do this with zero change in _bt_checkkeys() after all.
The amount of information passed down to an ordinary sk_func isn't
sufficient to do what the row-compare subroutine would need to do:
it needs access to the whole indextuple, not only the first column's
value, plus access to the direction and continuescan variables. We
could add extra parameters to what gets passed, but that's certainly
no cheaper than adding a test on some sk_flags bits. And having the
row comparison logic inside bt_checkkeys is probably more understandable
than having a separate subroutine with strange calling conventions.
I think given adequate documentation in skey.h, either representation
is about the same as far as the source-of-bugs argument goes. The main
risk you get from a Plan-B approach is that it's easier to fail to
notice bugs of omission, where a piece of code looking at a ScanKey
needs to do something special with a row-compare key and omits to do so.
At least that's what I'm guessing at the moment --- I haven't actually
tried to code up any of the changes yet. In any case, since we are only
intending to support this for searches of btree indexes, there are not
that many pieces of code that will be concerned with it. I think it's
just _bt_first, _bt_preprocess_keys, _bt_checkkeys, and
ExecIndexBuildScanKeys. Everyplace else will be dealing only in
"simple" ScanKeys with no row comparisons.
regards, tom lane
