Re: More WITH

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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

David Fetter <david(at)fetter(dot)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:

In response to

Browse pgsql-hackers by date

  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