Re: Internal design of MERGE, with Rules
От | Simon Riggs |
---|---|
Тема | Re: Internal design of MERGE, with Rules |
Дата | |
Msg-id | 1209657752.4264.17.camel@ebony.site обсуждение исходный текст |
Ответ на | Re: Internal design of MERGE, with Rules (Sam Mason <sam@samason.me.uk>) |
Список | 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 по дате отправления: