From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Hannu Krosing <hannu(at)2ndquadrant(dot)com>, David Fetter <david(at)fetter(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: DO ... RETURNING |
Date: | 2013-06-11 14:39:37 |
Message-ID: | CAHyXU0xuTQw2pfdRZQyA4WOa0jK-7-GQ5bZ=4amLS37hXqY3sQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jun 11, 2013 at 6:07 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
> 2013/6/11 Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>:
>> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2013-06-11 14:45:55 | Re: DO ... RETURNING |
Previous Message | Hannu Krosing | 2013-06-11 14:37:21 | Re: JSON and unicode surrogate pairs |