Tom Lane wrote: <blockquote cite="mid:25421.1214438480@sss.pgh.pa.us" type="cite"><pre wrap="">Jan Urbański <a
class="moz-txt-link-rfc2396E"
href="mailto:j.urbanski@students.mimuw.edu.pl"><j.urbanski@students.mimuw.edu.pl></a>writes: </pre><blockquote
type="cite"><prewrap="">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. </pre></blockquote><pre wrap="">
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... </pre></blockquote><br /> I agree - a byte-wise
comparisonof the internal encoding might be inadequate (compare "0.0e+1" to "0.0e+2" is "not equal" for instance?). If
theposter 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
thewrong assumption, and I really like that PostgreSQL will refuse to do things rather than silently continue to do
whatmay be the wrong thing (MySQL silent truncation when assigning into a varchar(8) for example).<br /><br /> The
problemhere seems to that "point" should have an equality operator?<br /><br /> Cheers,<br /> mark<br /><br /><pre
class="moz-signature"cols="72">--
Mark Mielke <a class="moz-txt-link-rfc2396E" href="mailto:mark@mielke.cc"><mark@mielke.cc></a>
</pre>
