Re: Creating a VIEW with a POINT column

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

Le jeudi 26 juin 2008, Tom Lane a écrit :
> Yeah. The GROUP BY case is even more annoying, because we *have* the
> planner/executor infrastructure to do it via hashing; but the parser
> barfs immediately if there is not btree opclass support for the type.
> I'm not sure how to fix the parser and the parsetree representation
> to be agnostic about hash versus sort implementations --- any thoughts?

Would it be possible to add some semantics to the operator itself?
I'm thinking about indicating that an operator is the equality one without
resorting to OPCLASS and while at it adding the notion of transitivity to
operators (which you'd like to abuse for some joins conditions iirc).

The CREATE OPERATOR =(type, type) (... EQUALITY ...) would give the
information to PostgreSQL and its planner. I'm not sure it current operator
catalog allows us to have a unique constraint for an equality operator for a
given couple of (LEFTARG, RIGHARG), though.

Would this help?
--
dim

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jiri Dvorak 2008-06-26 11:40:44 TODO assignment
Previous Message Pavel Stehule 2008-06-26 11:32:05 Re: plpgsql: Is ELSE IF supported or not?