Re: More WITH

On Fri, Aug 21, 2015 at 2:53 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> The existing syntax for FETCH already includes a way to specify the
>> number of rows you want to fetch, as in this example from the
>> documentation:
>> FETCH FORWARD 5 FROM liahona;
>> Why wouldn't that work here too?
>
> Mm, okay, but you still have the other objections to address.
>
> (And it remains the case that you can do this today with a plpgsql
> function, which solves the indeterminate-rowtype problem by nailing
> down the rowtype at the function result level.)

Sure, I'm not wildly in love with the feature and am not volunteering
to implement it. The EXPLAIN case seems more useful to me, but I'm
not volunteering to implement that either. But I don't think they are
insane propositions as you seem to be suggesting. Creating a wrapper
function works, but it's not obvious to non-experts that that's what
you need to do, and it's not terribly convenient anyway. It's kind of
silly to say, well, we can generate these rows on the server and ship
them back to the client, but we can't generate them on the server and
then post-process them in some way. That kind of composability is a
central advantage of SQL, and I'm sure that if we had it here it would
get used. But it's not a five-minute job to make it work properly,
either. Or even a five-day job.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company