Re: PL/pgSQL PERFORM with CTE
От | David E. Wheeler |
---|---|
Тема | Re: PL/pgSQL PERFORM with CTE |
Дата | |
Msg-id | 8467C2D3-1560-4673-9A26-4F41C9ECE257@justatheory.com обсуждение исходный текст |
Ответ на | Re: PL/pgSQL PERFORM with CTE (Pavel Stehule <pavel.stehule@gmail.com>) |
Список | pgsql-hackers |
On Aug 27, 2013, at 3:10 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote: > CREATE PROCEDURE foo() > BEGIN > SELECT 1,2; > SELECT 2; > SELECT 3,4 > END; > > And is not strange expect a result > > CALL foo() > > 1,2 > 2 > 3,4 > > Procedure is a script (batch) moved to server side for better performance and better reuse. I am not familiar with procedures, being a long time Postgres guy, but you’re right that it never occurred to me that theybe thought of as batch files. Still, this is PL/pgSQL we’re talking about, not TSQL or SQL/PSM anything else. Perhaps your syntax suggestions make sensethere, in which case, when you develop such functionality to Postgres, you would need to figure out how to get PERFORMto work with CTEs. But PL/pgSQL requires an explicit key word to return data, and I am hard pressed to see why thatwould change when it is used in procedures. And that makes PERFORM unnecessary, IME. > You should not thinking about procedures like void functions, because it is a little bit different creature - and voidfunctions is significantly limited in functionality. > > My proposal is consistent - no result goes to /dev/null without special mark. It is disabled (in function) or it goes toclient (in procedures). Consistent, yes. But I’m not convinced -- and I’m *certainly* not convinced that PERFORM should be required to discard queryresults in PL/pgSQL *functions*, which is the issue on the table now. Best, David
В списке pgsql-hackers по дате отправления: