2012/8/24 Craig Ringer <ring...@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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
