On Fri, Aug 23, 2013 at 5:07 PM, Tom Lane <<a href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>> wrote:<br
/>>Josh Berkus <<a href="mailto:josh@agliodbs.com">josh@agliodbs.com</a>> writes:<br />>> Currently the
onlyway to return query results to the caller is to use<br /> >> some form of RETURN. It is 100% consistent.<br
/>><br/>> I don't find it consistent at all, because what that means is that the<br />> data is to be returned
tothe SQL statement that called the function.<br /> ><br />> What's more, the point of any such extension needs
tobe to allow<br />> *multiple* resultsets to be returned to the client --- if you only need<br />> one, you can
havethat functionality today with plain old SELECT FROM<br /> > myfunction(). And returning some data but
continuingexecution is surely<br />> not consistent with RETURN.<br /><br />With set returning functions, RETURN
QUERYetc means 'yield this data' -- which is pretty weird -- so your point only holds true for unadorned return (not
RETURNNEXT , RETURN QUERY, etc). So I guess it's hard to claim RETURN means 'return control' though in a procedural
sense. In a perfect world, maybe a separate keyword could have been made to distinguish those cases (e.h. YIELD QUERY),
soI agree (after some reflection) with the spirit of your point. It's not good to have principle keywords do markedly
differentthings.<br /><br />> Basically it seems that we have two choices for how to represent this<br />>
(hypothetical)future functionality:<br />><br />> 1. Define SELECT without INTO as meaning return results
directlyto client;<br />><br /> > 2. Invent some new syntax to do it.<br />><br />> In a green field I
thinkwe'd want to do #2, because #1 seems rather<br />> error-prone and unobvious. The only real attraction of #1,
IMO,is that<br />> it's consistent with T-SQL. But that's not a terribly strong argument<br /> > given the many
existinginconsistencies between T-SQL and plpgsql.<br /><br />Very good points. I think the only compelling case for
#1that could be made would be to improve compatibility with pl/sql -- from what I can see Oracle has not defined the
behavior(that is, in pl/sql select must have INTO) but maybe someone could comment on that.<br /><br />> BTW, what
aboutINSERT/UPDATE/DELETE RETURNING? Do we want to let<br />> these execute and throw away the data? The argument
thatthis would<br />> be a feature seems a lot weaker than for SELECT, because after all you<br /> > could
usuallyjust leave off the RETURNING clause. But I'm sure somebody<br />> will say they want to put a function with
side-effectsinto RETURNING<br />> and then ignore its output.<br /><br />If we agree to relax PERFORM, those should
berelaxed on the same basis. In fact, this is conclusive evidence that PERFORM is obsolete: it hails from the days
whereSELECT was the only data returning DML.<br /><br />merlin<br />