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 03:43:27
Message-ID: 4863105F.2080202@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:
>> 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.
> 
> Well, you're still missing my point, which is how do you decide which
> operator is "equality"?  It was already pointed out upthread that
> ignoring the type's operators and using bitwise comparison is a pretty
> sucky alternative.  The only infrastructure in Postgres that can
> identify which operators have which semantics is index opclasses.

All right, I get it. You get the equality operator from the index 
opclass for the type, I didn't understand fully how it worked.

> I see two possible TODO items in this discussion.  One is that type
> "point" is sorely lacking in opclass support.  The other is that it
> might be interesting to support DISTINCT in cases where only a hash
> opclass, not a btree opclass, is available --- which would lead to
> a hash-aggregation-like implementation instead of sort-and-uniq.

Same thing for GROUP BY. One last remark: unless something is done about 
it in 8.4, maybe it is worthwhile to change the error message (which 
clearly confused Nick) and add some documentation about why you can't 
use DISTINCT with types without a btree index opclass?

-- 
Jan Urbanski
GPG key ID: E583D7D2

ouden estin

In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2008-06-26 03:58:09
Subject: Re: [0/4] Proposal of SE-PostgreSQL patches
Previous:From: Robert HaasDate: 2008-06-26 03:34:32
Subject: Re: Planner creating ineffective plans on LEFT OUTER joins

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