Re: DO ... RETURNING

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: DO ... RETURNING
Дата
Msg-id CAHyXU0xuTQw2pfdRZQyA4WOa0jK-7-GQ5bZ=4amLS37hXqY3sQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: DO ... RETURNING  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: DO ... RETURNING  (Stephen Frost <sfrost@snowman.net>)
Список 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 по дате отправления:

Предыдущее
От: Hannu Krosing
Дата:
Сообщение: Re: JSON and unicode surrogate pairs
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: DO ... RETURNING