From: | David Fetter <david(at)fetter(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Craig Ringer <craig(at)2ndquadrant(dot)com>, PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: More WITH |
Date: | 2015-08-19 13:03:12 |
Message-ID: | 20150819130312.GF11258@fetter.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Aug 18, 2015 at 11:23:32PM -0400, Tom Lane wrote:
> 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?
So FETCH is not a good candidate for inclusion in WITH, at least until
someone comes up with some meaningful definition of what this would
mean.
Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
From | Date | Subject | |
---|---|---|---|
Next Message | Kohei KaiGai | 2015-08-19 13:19:56 | Re: DBT-3 with SF=20 got failed |
Previous Message | Daniel Verite | 2015-08-19 13:02:59 | Re: [patch] psql tab completion for grant execute |