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