Re: Internal design of MERGE, with Rules - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Internal design of MERGE, with Rules
Date
Msg-id 1209657752.4264.17.camel@ebony.site
Whole thread Raw
In response to Re: Internal design of MERGE, with Rules  (Sam Mason <sam@samason.me.uk>)
List 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



pgsql-hackers by date:

Previous
From: Andrew Sullivan
Date:
Subject: Re: Protection from SQL injection
Next
From: PFC
Date:
Subject: Re: Protection from SQL injection