2013/8/23 Merlin Moncure <mmonc...@gmail.com> > On Fri, Aug 23, 2013 at 12:51 PM, Josh Berkus <j...@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. PERFORM must be fixed, but should be used. Regards Pavel > > merlin >
