Heikki Linnakangas <heikki@enterprisedb.com> writes:
> I'd like to see this implemented with more general collation support in
> mind.
I'm really not prepared to buy into that, simply because it puts ICU or
some equivalent large chunk of new code into the critical path to finish
what I'm doing. The fact that pathkeys will become structs will
probably make it easier to add collation later (adding another field to
the struct won't mean a wholesale notational change), but that doesn't
mean I have to do it now.
> The NULLS FIRST/LAST support, as well as ascending and descending
> orderings would be special cases of the general collation and collation
> conversion machinery.
That seems like a bad idea, because nulls first/last and asc/desc
ordering are valid concepts for all btree-indexable datatypes, whereas
collation is only meaningful for text. Besides, that approach just
moves the bloat over from too-many-opclasses to too-many-collations; do
we really want to need four collation objects for each basic collation?
regards, tom lane
