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

Re: Creating a VIEW with a POINT column

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jan Urbański <j(dot)urbanski(at)students(dot)mimuw(dot)edu(dot)pl>
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:12:46
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
=?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.

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.
The value as far as type point is concerned is that you'd not have to
invent some arbitrary linear sort ordering for points.

The idea of supporting DISTINCT with neither type of opclass available
seems to me to be indefensible on *both* semantics and performance

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Robert HaasDate: 2008-06-26 03:34:32
Subject: Re: Planner creating ineffective plans on LEFT OUTER joins
Previous:From: Bruce MomjianDate: 2008-06-26 02:53:24
Subject: Re: Proposed Patch - LDAPS support for servers on port 636 w/o TLS

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