Re: wCTE behaviour

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi>
Cc: David Fetter <david(at)fetter(dot)org>, Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Yeb Havinga <yebhavinga(at)gmail(dot)com>, Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>
Subject: Re: wCTE behaviour
Date: 2011-02-25 16:12:31
Message-ID: 22488.1298650351@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi> writes:
> On 2011-02-25 1:36 AM, Tom Lane wrote:
>> Why is it necessary to hack the portal logic at all? The patch seems to
>> work for me without that. (I've fixed quite a few bugs though, so maybe
>> what this is really doing is masking a problem elsewhere.)

> Without hacking it broke when PQdescribePrepared was called on a
> prepared query like:

> WITH t AS (DELETE FROM foo)
> SELECT 1;

> Not sure if that's an actual problem, but it seemed like something worht
> fixing.

I can't replicate such a problem here --- do you have a concrete test
case? ISTM the issue would only have been a problem back when you
were trying to generate multiple PlannedStmts from a query like the
above. The current implementation with everything in one plantree
really ought to look just like a SELECT so far as the portal code
is concerned.

>> Also, why are we forbidding wCTEs in cursors? Given the current
>> definitions, that case seems to work fine too: the wCTEs will be
>> executed as soon as you fetch something from the cursor. Are you
>> just worried about not allowing a case that might be hard to support
>> later?

> Honestly, I have no idea. It might be a leftover from the previous
> design. If it looks like it's easy to support, then go for it.

Right now I'm thinking that it is best to continue to forbid it.
If we go over to the less-sequential implementation that I'm advocating
in another thread, the timing of the updates would become a lot less
predictable than I say above. If we refuse it for now, we can always
remove the restriction later, but the other way is more painful.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Marko Tiikkaja 2011-02-25 16:24:04 Re: wCTE behaviour
Previous Message Marko Tiikkaja 2011-02-25 16:03:46 Re: wCTE: why not finish sub-updates at the end, not the beginning?