Re: FETCH in subqueries or CTEs
От | Pavel Stehule |
---|---|
Тема | Re: FETCH in subqueries or CTEs |
Дата | |
Msg-id | CAFj8pRBdh9DbPHkpwiifXMc+pxo0XYjTdhcJ8K-bPO4eUV7A+g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: FETCH in subqueries or CTEs (Craig Ringer <ringerc@ringerc.id.au>) |
Список | pgsql-general |
2012/8/24 Craig Ringer <ringerc@ringerc.id.au>: > On 08/24/2012 12:34 PM, Pavel Stehule wrote: > >> you can't mix planned and unplanned statements together - think about >> stored plans every time > > > Thanks Pavel and Jeff. > > I can't say I fully understand the arguments, but I'll take it that > accepting cursors in CTEs or subqueries wouldn't make sense. I guess the > main issue really is that you'd have to materialize them anyway to avoid > issues with multiple scans, so there's little point having a cursor. > > I didn't find a reasonable way to simply fetch a cursor into a (possibly > temporary) table, like: > > INSERT INTO sometable FETCH ALL FROM somecursor; it should be implemented as function - like materialize_cursor(cursor, table) I would to see full support of stored procedures (with multirecordsets) rather. Regards Pavel > > ... which could be handy with PL/PgSQL functions that return multiple > refcursors. It only seems to be possible via a PL/PgSQL wrapper that loops > over the cursor and returns a rowset. > > -- > Craig Ringer
В списке pgsql-general по дате отправления: