Обсуждение: pgAdmin III: EDB procedures with non void return types not handled properly

Hi,

With the latest refactorings in the EDBAS90 source base, procedures (CREATE PROCEDURE objects) can have non void return types in some cases. For example:

edb=# create or replace procedure set_Order (
    v_index        INOUT  integer
) AS                           
    counter    integer;        
BEGIN                          
    counter := 0;              
    v_index := counter;         
END;
CREATE PROCEDURE
edb=# select protype, prorettype from pg_proc where proname = 'set_order';
 protype | prorettype
---------+------------
 1       |         23

Here the prorettype is "int4" and protype is set to 1 to indicate that this is a procedure.

The existing pgadmin source currently expects procedures to have "void" return types only. Now that the "protype" column (which can differentiate between functions and procedures) is available since 8.1, we can use it to identify such objects without resorting to "void" type checks. Ofcourse we need to retain existing checks for older versions.

PFA, patch which does the same.

Regards,
Nikhils

On Mon, Jan 31, 2011 at 7:17 AM, Nikhil S <nixmisc@gmail.com> wrote:
> Hi,
>
> With the latest refactorings in the EDBAS90 source base, procedures (CREATE
> PROCEDURE objects) can have non void return types in some cases. For
> example:
>
> edb=# create or replace procedure set_Order (
>     v_index        INOUT  integer
> ) AS
>     counter    integer;
> BEGIN
>     counter := 0;
>     v_index := counter;
> END;
> CREATE PROCEDURE
> edb=# select protype, prorettype from pg_proc where proname = 'set_order';
>  protype | prorettype
> ---------+------------
>  1       |         23
>
> Here the prorettype is "int4" and protype is set to 1 to indicate that this
> is a procedure.
>
> The existing pgadmin source currently expects procedures to have "void"
> return types only. Now that the "protype" column (which can differentiate
> between functions and procedures) is available since 8.1, we can use it to
> identify such objects without resorting to "void" type checks. Ofcourse we
> need to retain existing checks for older versions.
>
> PFA, patch which does the same.

Thanks. This seems to be a bug in fact, as it could mis-identify a
function that returns void as a procedure.

Applied for 1.12.3 and master.


--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company