2013/6/11 Stephen Frost <sfrost@snowman.net>:
> * Pavel Stehule (pavel.stehule@gmail.com) wrote:
>> 2013/6/11 Stephen Frost <sfrost@snowman.net>:
>> > And this still has next-to-nothing to do with the specific proposal that
>> > was put forward.
>> >
>> > I'd like actual procedures too, but it's a completely different and
>> > distinct thing from making DO blocks able to return something.
>>
>> I think so it is related - we talk about future form of DO statement -
>> or about future form of server side scripting.
>
> I don't believe there's any intent to ever have DO used for stored
> procedures. Not only are stored procedures deserving of their own
> top-level command (eg: CALL, as has been discussed before..), but I
> believe they would necessairly have different enough semantics that
> shoe-horning them into DO would end up breaking backwards compatibility.
In this moment, DO doesn't support any feature that is in conflict
with stored procedure functionality, because it is based on functions,
and then it have to have limited functionality
Syntax of procedures and functions is relatively well defined
CREATE FUNCTION foo(..) ----> SELECT expression contains foo call
CREATE PROCEDURE foo(..) ---> CALL foo()
Now anonymous code block is based on functions, but it can be changed
to respect context or usage without lost of compatibility.
DO $$ ... $$ -- procedural behave -- just execute server side scripts
CTE DO RETURNING $$ ... $$ -- functional behave, functional limits.
Pavel
>
> Thanks,
>
> Stephen