Re: DO ... RETURNING - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: DO ... RETURNING
Date
Msg-id CAHyXU0xuTQw2pfdRZQyA4WOa0jK-7-GQ5bZ=4amLS37hXqY3sQ@mail.gmail.com
Whole thread Raw
In response to Re: DO ... RETURNING  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: DO ... RETURNING
List pgsql-hackers
On Tue, Jun 11, 2013 at 6:07 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> 2013/6/11 Dimitri Fontaine <dimitri@2ndquadrant.fr>:
>> Pavel Stehule <pavel.stehule@gmail.com> writes:
>>>   FOR r IN pg_databases
>>>   LOOP
>>>     CONNECT r.dbname;
>>
>> Do you mean that you want to run this DO block on the client side?
>
> no, really no.
>
> I am thinking about some outer server side process, where these
> scripts will be executed. Maybe other usage for background worker
> process

+ 1

I agree with all your comments pretty much down the line.  Need top
level CALL that supports parameterization and multiple sets that
utilizes background worker (we have example spi worker that gives some
hints about how pl/pgsql could be made to work).  Because it's top
level (can't even be inlined to CTE), we can access behaviors that are
not possible in current pl/pgsql, for example setting transaction
isolation in advance of snapshot and changing database connection
mid-procedure.

merlin



pgsql-hackers by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: JSON and unicode surrogate pairs
Next
From: Stephen Frost
Date:
Subject: Re: DO ... RETURNING