Andres Freund <andres@anarazel.de> writes:
> On 2018-12-14 14:25:30 -0500, Tom Lane wrote:
>> Now, it's certainly true that nameeq() doesn't need a collation spec
>> today, any more than texteq() does, because both types legislate that
>> equality is bitwise. But if we leave ExecBuildGroupingEqual like this,
>> we're mandating that no type anywhere, ever, can have a
>> collation-dependent notion of equality. Is that really a restriction
>> we're comfortable with? citext is sort of the poster child here,
>> because it already wishes it could have collation-dependent equality.
> Don't we rely on that in other places too?
Possibly; the regression tests probably don't stress type "name" too hard,
so my Assert might well not be finding some other code paths that do
likewise. The question at hand is whether we're going to say those are
bugs to be fixed, or that it's OK as-is.
> I think one issue here is that it's not clear how it'd be sensible to
> have collation dependent equality for cases where we don't have a real
> way to override the collation for an operation. It's not too hard to
> imagine adding something to GROUP BY, but set operations seem harder.
Yeah, fair point. But we've got comparable issues with respect to
which equality operator to use in the first place, for a lot of these
constructs, cf
https://www.postgresql.org/message-id/10492.1531515255@sss.pgh.pa.us
(which I've not made any further progress on). Unless you want to
throw up your hands and say that *all* equality is bitwise, we need
to think about ways to deal with that.
regards, tom lane