Re: DECLARE CURSOR must not contain data-modifying statements in WITH

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: DECLARE CURSOR must not contain data-modifying statements in WITH
Date: 2011-09-23 15:20:46
Message-ID: CA+TgmobCKwc=bDfP64n91e1KKkM2OkcON61RuV-gWgK2x5mFxQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Sep 23, 2011 at 10:53 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> One could argue that its a easier to implement it using a wCTE because the
> query will be simply materialize the query upfront.
> That makes handling the case where somebody fetches 3 tuples from a query
> updating 10 easier.
>
> Thats a bit harder for the normal cursor case because there is no tuplestore
> around to do that (except the WITH HOLD case where that is only used on
> commit...).
>
> I find it an acceptable way to enforce using a CTE to do cursors on DML because
> it makes it more clear that they will be fully executed on start...

Hmm, maybe. But if that's true, why does the comment read the way it
does? If the updates all occur at the beginning, that wouldn't be
"surprising", would it?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2011-09-23 15:22:09 Re: memory barriers (was: Yes, WaitLatch is vulnerable to weak-memory-ordering bugs)
Previous Message Robert Haas 2011-09-23 14:56:43 Re: [pgsql-advocacy] Unlogged vs. In-Memory