Re: Creating a VIEW with a POINT column

From: Jan Urbański <j(dot)urbanski(at)students(dot)mimuw(dot)edu(dot)pl>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Mark Mielke <mark(at)mark(dot)mielke(dot)cc>, Nick <nboutelier(at)hotmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Creating a VIEW with a POINT column
Date: 2008-06-26 02:26:19
Message-ID: 4862FE4B.7020001@students.mimuw.edu.pl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= <j(dot)urbanski(at)students(dot)mimuw(dot)edu(dot)pl> writes:
>>> Tom Lane wrote:
>>>> 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...
>
>> The way I see it there's nothing wrong with the definition of DISTINCT
>> and for types that can't be compared there is no way of calculating
>> distinct values other than comparing every element to every other.
>
> "for types that can't be compared"? Do you not see the logical
> disconnect in that sentence?

OK, there might have been a mental shortcut there. "Can't be compared"
was supposed to mean "can't decide whether one value of that type is
bigger than another". Doing DISTINCT without an equality operator is
nonsense. Doing it without a comparision operator is only very slow.

--
Jan Urbanski
GPG key ID: E583D7D2

ouden estin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-06-26 02:36:09 Re: Planner creating ineffective plans on LEFT OUTER joins
Previous Message Tom Lane 2008-06-26 02:19:41 Re: Creating a VIEW with a POINT column