Re: [HACKERS] Internal design of MERGE, with Rules

2008-05-08 Thread Simon Riggs
On Wed, 2008-04-30 at 16:58 +0100, Simon Riggs wrote: > The main query will then look like this > > select target.ctid > ,case when-not-matched (as above) > ,case when-matched (as above) > ,(all other columns required for side queries) > from left outer join on > whe

Re: [HACKERS] Internal design of MERGE, with Rules

2008-05-01 Thread Simon Riggs
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 in

Re: [HACKERS] Internal design of MERGE, with Rules

2008-04-30 Thread Sam Mason
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

[HACKERS] Internal design of MERGE, with Rules

2008-04-30 Thread Simon Riggs
MERGE looks like it may need some new infrastructure to support it, depending upon the implementation route. Guidance and discussion requested from main hackers, if possible. This is a separate post because there's no further discussion here on the external behaviour of MERGE, or its concurrency/l