ScanKey representation for RowCompare index conditions

There's one nontrivial decision still to make about how to implement
proper per-spec row-comparison operations, namely: how a row
comparison ought to be represented in the index access method API.
The current representation of index conditions in the AM API is an
array of ScanKey structs, one per "indexcol op constant" index
condition, with implicit ANDing across all the conditions.  There
are various bits of code that require the ScanKeys to appear in order
by index column, though this isn't inherent in the data structure
itself.

Short of a fundamental redesign of the data structure, I can see two
plausible approaches to adding row-wise comparisons:

A. Include all the elements of the row comparison as separate entries
in the ScanKey array, and mark them (probably via sk_flags bits) to
show that they form a row condition rather than independent tests.
Unless we want to add more fields to ScanKey, we'd have to rely on
the order of the ScanKey entries to show the relationship of the
conditions (ie, which condition is part of which row comparison,
and what its column position is within the row).

B. Place a single entry for the row comparison in the main ScanKey
array, with a special sk_func pointer pointing to a function that
does a row-wise comparison.  The sk_argument field would point to
a subsidiary ScanKey array containing the actual index columns and
data values for the row elements.  sk_attno would reference the first
(leftmost) index column used by the row comparison.  We'd still want
an sk_flags bit to indicate that this is a row comparison, probably.

I'm currently leaning to plan B, on the grounds that:

1. It would require no changes in _bt_checkkeys(), which is the only
user of the data structure that is particularly performance-critical.
With plan A we'd be adding at least a few cycles to _bt_checkkeys in
all cases.  Plan B avoids that at the cost of an extra level of function
call to do a row comparison.  Given the relative frequency of the two
sorts of index conditions, this has to be the better tradeoff to make.

2. There's quite a bit of logic in btree indexscan setup that would find
it convenient to treat a row comparison as if it were a single condition
on just its leftmost column.  This may end up being nearly a wash, but
I think that plan A would make the setup code a shade more complex than
plan B would.  In particular, the rules about valid orderings of the
ScanKey entries would be complicated under plan A, whereas under plan
B it's still clear where everything belongs.

Any thoughts?  Anyone see a good plan C, or a serious flaw that I'm
missing in either of these ideas?
        regards, tom lane