Josh Berkus <josh@agliodbs.com> writes:
> On 08/23/2013 01:06 PM, Marko Tiikkaja wrote:
>>> Is there some reason we wouldn't use RETURN QUERY in that case, instead
>>> of SELECT? As I said above, it would be more consistent with existing
>>> PL/pgSQL.
>> How would using the same syntax to do an entirely different thing be
>> consistent?
> Currently the only way to return query results to the caller is to use
> some form of RETURN. It is 100% consistent.
I don't find it consistent at all, because what that means is that the
data is to be returned to the SQL statement that called the function.
What's more, the point of any such extension needs to be to allow
*multiple* resultsets to be returned to the client --- if you only need
one, you can have that functionality today with plain old SELECT FROM
myfunction(). And returning some data but continuing execution is surely
not consistent with RETURN.
Basically it seems that we have two choices for how to represent this
(hypothetical) future functionality:
1. Define SELECT without INTO as meaning return results directly to client;
2. Invent some new syntax to do it.
In a green field I think we'd want to do #2, because #1 seems rather
error-prone and unobvious. The only real attraction of #1, IMO, is that
it's consistent with T-SQL. But that's not a terribly strong argument
given the many existing inconsistencies between T-SQL and plpgsql.
BTW, what about INSERT/UPDATE/DELETE RETURNING? Do we want to let
these execute and throw away the data? The argument that this would
be a feature seems a lot weaker than for SELECT, because after all you
could usually just leave off the RETURNING clause. But I'm sure somebody
will say they want to put a function with side-effects into RETURNING
and then ignore its output.
regards, tom lane
