Re: functions vs stored procedures - Mailing list pgsql-admin

From Ezequiel Tolnay
Subject Re: functions vs stored procedures
Date
Msg-id db71hd$1eqd$1@news.hub.org
Whole thread Raw
In response to Re: functions vs stored procedures  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: functions vs stored procedures  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-admin
Thanks for the tip, but unfortunately id didn't address any of my
concerns. I alreay use the version 8, and I'm aware of the possibility
of using arrays for the results, which allows for some flexibility. But
unfortunately arrays are not records, and I'm limited to values of the
same types, and cannot refer the values from their column names. To
create this function I also have to build the arrays for each result,
casting all the values to text in a way that I would be able to convert
back to the original value.

As it is, the workaround is more complicated than the problem itself, so
I think a script droping and recreating all the types and the functions
that use them is preferred.

¿Does anyone know if there is a reason why PostgreSQL lacks stored
procedures? i.e. the type that is executed with the EXECUTE command
(e.g. EXECUTE myproc(1, 2, 3)) and capable of returning an arbitrary
number of rowsets of arbitrary types.

Thanks anyway :o)

Ezequiel Tolnay

Tom Lane wrote:
> Ezequiel Tolnay <mail@etolnay.com.ar> writes:
>
>>I just can't get used to the annoyance of having to create a type for
>>every single function that returns a rowset. It is frankly cumbersome.
>
>
> Yup.  See coming attractions at, eg,
> http://developer.postgresql.org/docs/postgres/xfunc-sql.html#XFUNC-OUTPUT-PARAMETERS
> http://developer.postgresql.org/docs/postgres/plpgsql-declarations.html#PLPGSQL-DECLARATION-ALIASES
>
>             regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>

pgsql-admin by date:

Previous
From: Michael Fuhr
Date:
Subject: Re: Error message: cannot identify operator 184
Next
From: Tom Lane
Date:
Subject: Re: Error message: cannot identify operator 184