Re: array support patch phase 1 patch

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> That is fine, but what if someone defines a new data type and different
> ordering operators, say << and <<<. Then I'd think he should be able to
> use those automatically on the array type whose elements are the new type.

I'm unconvinced that this can or should be "automatic". How are we
supposed to know what the appropriate combination logic is to extend
a random comparison operator to arrays? For operators that follow
the ordinary <, =, > logic we know what to do, but if someone invents
a new operator that doesn't fit into that structure then I don't think
we can be expected to handle it.

If you're complaining that equality_oper() and ordering_oper() are
bogus, I'd tend to agree, but that hardly affects the validity of this
patch. The present definition of ordering_oper() isn't too horrible
(since it looks for mergejoinability rather than depending on any
assumptions about names) but equality_oper() is hokey. It'd be nice
to have some more catalog-driven way of identifying the equality operator
for a datatype.

BTW, it might be better for array_cmp to insist that the array element
type have a default btree opclass, and use the comparison proc from that
opclass in place of equality_oper() and ordering_oper(). This'd be
faster (only one call per comparison) as well as more semantically pure.

I've got some other problems with this patch (I still don't understand
what the hacking on aggregates is supposed to accomplish, for example)
but the array comparison stuff seems relatively straightforward.

regards, tom lane