From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | Sam Mason <sam(at)samason(dot)me(dot)uk> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Internal design of MERGE, with Rules |
Date: | 2008-05-01 16:02:32 |
Message-ID: | 1209657752.4264.17.camel@ebony.site |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 2008-05-01 at 00:26 +0100, Sam Mason wrote:
> On Wed, Apr 30, 2008 at 04:58:52PM +0100, Simon Riggs wrote:
> > That means we probably need to introduce new infrastructure in the tcop
> > or executor modules to handle queries-within-queries. This isn't
> > special-casing MERGE so much as introducing infrastructure for a new
> > class of query, such as MERGE, REPLACE, INSERT ELSE UPDATE. (Merge
> > itself does cover almost all cases of this type of query, but we'd be
> > able to fairly easily support all of the different syntax).
> >
> > MERGE would then be represented by a query that has many "side
> > queries" (so called so we don't confused calling them sub-queries).
>
> Why make them special cases? (I'm sure there's a good reason!)
Well, I'm not making them special cases. The infrastructure would be
generalised for any statement type that wanted to do roughly this.
> I've sometimes wanted to be able to put DML statements inside SELECT
> statements. The following is a slightly reasonable example:
>
> INSERT INTO ilog (i,ts,n)
> SELECT i, now(), COUNT(*)
> FROM (
> INSERT INTO bar (x,y)
> SELECT 5, n
> FROM baz
> WHERE i = 10
> RETURNING i) x
> GROUP BY i;
OK, but that's not what I'm working on... useful as it sounds.
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-05-01 16:30:48 | Let the commit fest begin! |
Previous Message | Andrew Sullivan | 2008-05-01 15:47:04 | Re: Protection from SQL injection |