On Fri, Aug 23, 2013 at 12:51 PM, Josh Berkus <josh@agliodbs.com> wrote: > Pavel, > >> But it can have a different reason. In T-SQL (Microsoft or Sybase) or MySQL >> a unbound query is used to direct transfer data to client side. > > Are you planning to implement that in PL/pgSQL? > > Currently, PL/pgSQL requires RETURN ____ in order to return a query > result to the caller. Is there some reason we'd change that? > > If you're implementing TSQL-for-PostgreSQL, of course you might want to > have different behavior with SELECT. However, TSQL is not PL/pgSQL.
I don't think Pavel's point makes sense in the context of functions. With stored procedures it might though -- but I don't see why that we need to reserve behavior for SELECT without INTO -- it can behave differently when executed with a hypothetical CALL.
I think so is not good if some programming language functionality does one in one context (functions) and does something else in second context (procedures).
On second hand, I am thinking so requirement PERFORM is good. A query that does some, but result is ignored, is strange (and it can be a performance fault), so we should not be too friendly in this use case.