On Fri, Aug 21, 2015 at 2:53 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers