From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Darren Duncan <darren(at)darrenduncan(dot)net> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: returning multiple result sets from a stored procedure |
Date: | 2010-09-09 20:17:43 |
Message-ID: | AANLkTikwUhUr+DUOQuCgXHR2mNi-h38hRH=HDJ1tRXU-@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2010/9/9 Darren Duncan <darren(at)darrenduncan(dot)net>:
> Pavel Stehule wrote:
>>
>> there are lot of questions - and I am not sure if procedures
>> implementation can be done in one release cycle. The basic questions:
>>
>> * should be special catalog for procedures or we will use pg_proc?
>> * how can be implemented OUT variables - the original implementation
>> is simple - it's just pointer, but it's not directly possible inside
>> postgres, because we use a MemoryContexts?
>> * how can be implement a CALL statement - as plan statement or as command?
>> * how can be implemented variables inside psql console, if we allows them?
>> * how can be implement an overloading of procedures - can we use for
>> selection OUT variables too?
>> * what is procedure? It's like void function, or it can return status
>> code like procedures in SQL/PSM (DB2)?
>>
>> --- As long years a stored procedures developer, I can say, so just
>> minimal implementation of procedures can help with writing little bit
>> more readable code for functions that return more then one scalar
>> result. But other features can be nice too - explicit transaction
>> control and unbind selects. But these features are killing gun.
>
> I've often considered that the main distinction between a function and a
> procedure is that the former is intended to be invoked as a value-resulting
> expression while the latter is intended to be invoked as a
> non-value-resulting statement. The SQL standard uses separate FUNCTION and
> PROCEDURE for these.
>
> Since Pg's FUNCTION already seems to take on both roles, so overloading the
> meaning of the FUNCTION keyword, like what a C function or a Perl sub does,
> where returning VOID means procedure, then what is being added by a distinct
> PROCEDURE? Or is the VOID-returning FUNCTION going to be deprecated or
> discouraged at the same time?
>
the overloading of function is based only on input parameters -
because there are not entered output variables - it is just some
record. But overloading of procedures, can be based on input and
output variables.
so I can to write
CREATE PROCEDURE foo(OUT a int)
...
and
CREATE PROCEDURE foo(OUT a varchar)
...
and then when I use a statement CALL is correct procedure selected
CALL foo(textvariable)
Regards
Pavel
> -- Darren Duncan
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-09-09 20:22:31 | Re: returning multiple result sets from a stored procedure |
Previous Message | Tom Lane | 2010-09-09 20:16:36 | Re: returning multiple result sets from a stored procedure |