Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group