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

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: (view raw, whole thread or download thread mbox)
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?

In response to

pgsql-hackers by date

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

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