Re: Creating a VIEW with a POINT column

Tom Lane wrote:
> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= <j(dot)urbanski(at)students(dot)mimuw(dot)edu(dot)pl> writes:
>
>> All three try to sort the table first, and as there's no comparision
>> operator for the POINT datatype, they fail. Which seems to be wrong - if
>> there is no comparision operator, you still can do DISTINCT, only less
>> efficiently.
>>
>
> Type point has no btree opclass, no hash opclass, and not even an
> operator named "=" (it looks like the functionality is named ~=
> for some odd reason). I'd be interested to hear either a proposal of
> a principled way to define DISTINCT, or a way to implement it that
> was better than comparing every element to every other element...
>

I agree - a byte-wise comparison of the internal encoding might be
inadequate (compare "0.0e+1" to "0.0e+2" is "not equal" for instance?).
If the poster is referring to a translation to string before comparing,
this could face similar issue. What if it's not a "point" but a
"fraction" - does "2/4" = "1/2"? With an operator implementing "=",
making any assumption may be making the wrong assumption, and I really
like that PostgreSQL will refuse to do things rather than silently
continue to do what may be the wrong thing (MySQL silent truncation when
assigning into a varchar(8) for example).

The problem here seems to that "point" should have an equality operator?

Cheers,
mark

--
Mark Mielke <mark(at)mielke(dot)cc>