On Tue, Jun 11, 2013 at 11:26 AM, Pavel Stehule <pavel.steh...@gmail.com> wrote: > 2013/6/11 Stephen Frost <sfr...@snowman.net>: >> * Pavel Stehule (pavel.steh...@gmail.com) wrote: >>> 2013/6/11 Stephen Frost <sfr...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
