| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
| Cc: | David Fetter <david(at)fetter(dot)org>, PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: More WITH |
| Date: | 2015-08-19 03:23:32 |
| Message-ID: | 14173.1439954612@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Craig Ringer <craig(at)2ndquadrant(dot)com> writes:
> On 18 August 2015 at 01:18, David Fetter <david(at)fetter(dot)org> wrote:
>> FETCH [in WITH]
> I'd be a huge fan of this one. I'd love to see FETCH in subqueries,
> too. Currently doing anything like this requires an ugly PL/PgSQL
> wrapper.
> The cursor would have to be known at plan-time so it could be
> interrogated for its types.
That's barely the tip of the iceberg of the problems with this idea.
How many rows would be fetched from the cursor? What row would it be
left on? Whatever answer you give will be wrong from some perspective,
but particularly that of giving the planner any freedom-of-action
to optimize such a query.
More generally, what would you hope to accomplish with such a construct
that wouldn't be better done by writing the cursor's underlying query
directly in the WITH clause?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2015-08-19 03:27:11 | Re: [DESIGN] ParallelAppend |
| Previous Message | Craig Ringer | 2015-08-19 03:16:17 | Re: How to compile, link and use a C++ extension |