On 2011-02-25 6:12 PM, Tom Lane wrote:
Marko Tiikkaja<marko.tiikk...@cs.helsinki.fi> writes:
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.
I don't have one right now (I lost the one I had because of a hardware
failure in a virtual machine), but I can write you one if you want to.
But see below.
The current implementation with everything in one plantree
really ought to look just like a SELECT so far as the portal code
is concerned.
The problem was that the old code was using PORTAL_MULTI_QUERY whenever
a wCTE was present. Are you saying that you are using
PORTAL_ONE_SELECT? Doesn't that have problems with triggers, for example?
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.
Fair enough.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
