On Tue, Jun 11, 2013 at 11:26 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> 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.
why does it have to be CTE?
merlin