Re: FETCH in subqueries or CTEs

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Craig Ringer <ringerc(at)ringerc(dot)id(dot)au>
Cc: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>, Jeff Davis <pgsql(at)j-davis(dot)com>
Subject: Re: FETCH in subqueries or CTEs
Date: 2012-08-24 13:46:56
Message-ID: CAFj8pRBdh9DbPHkpwiifXMc+pxo0XYjTdhcJ8K-bPO4eUV7A+g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

2012/8/24 Craig Ringer <ringerc(at)ringerc(dot)id(dot)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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2012-08-24 14:31:15 Re: FETCH in subqueries or CTEs
Previous Message Sahagian, David 2012-08-24 13:27:06 create table like . . . constraint names