Re: ORDER/GROUP BY expression not found in targetlist

Andreas Seltenreich <seltenreich(at)gmx(dot)de> writes:
> Tom Lane writes:
>> It's looking for an operator that is known to be semantically equality,
>> by virtue of being the equality member of a btree or hash opclass.
>> Type path has no such opclass unfortunately.

> As do lots of data types in the regression db while still having an
> operator providing semantic equivalence. I was hoping for someone to
> question that status quo. Naively I'd say an equivalence flag is
> missing in the catalog that is independent of opclasses.

[ shrug... ] I see little wrong with that status quo. For this
particular use-case, there are two ways we could implement DISTINCT: one
of them requires sorting, and the other requires hashing. So you would
need to provide that opclass infrastructure even if there were some other
way of identifying the operator that means equality.

Type path and the other geometric types lack any natural sort order so
it's hard to imagine making a default btree opclass for them. But a
default hash opclass might not be out of reach, given an exact equality
operator.

Another problem with the geometric types is that long ago somebody
invented "=" operators for most of them that have little to do with what
anyone would consider equality. The "path = path" operator just compares
whether the paths have the same number of points. A lot of the other ones
compare areas. It'd be hard to justify marking any of them as default
equality for the type.

regards, tom lane