I wonder why this is a problem in opfamilies but not collations. If we don't compare collations, wouldn't it make more sense to break out of the loop once the number of keys is reached?
It appears that INCLUDE columns might have collation defined.
For instance, following query is working:
create index t_s1_s2_idx on t (s1) include (s2 collate "en_US.UTF-8");
However, I don't see any point in defining collations here, because
INCLUDE attributes exist solely for index-only scans. So, index just
can return value of INCLUDE attribute "as is", no point to do something
with collation.
So, I propose to disable collations for INCLUDE attributes.
When this code was written, there was no question as to what length the opfamilies/collations the arrays were; it was obvious that they must be of the length of the index attributes. It's not obvious now. Maybe add a comment about that?
In b3b7f789 Tom have resized one array size from total number of
attributes to number of key attributes. And I like idea of applying the
same to all other array: make them sized to total number of attributes
with filling of absent attributes with 0.
> But it seems to me, field's names of > IndexInfo structure are a bit confused now: > int ii_NumIndexAttrs; /* total number of columns in index */ > int ii_NumIndexKeyAttrs; /* number of key columns in index */ > AttrNumber ii_KeyAttrNumbers[INDEX_MAX_KEYS]; > > ii_KeyAttrNumbers contains all columns, i.e. it contains ii_NumIndexAttrs > number of columns, not a ii_NumIndexKeyAttrs number as easy to think. > > I suggest rename ii_KeyAttrNumbers to ii_AttrNumbers or ii_IndexAttrNumbers. > Opinions?