Re: functions vs stored procedures
От | Ezequiel Tolnay |
---|---|
Тема | Re: functions vs stored procedures |
Дата | |
Msg-id | db71hd$1eqd$1@news.hub.org обсуждение исходный текст |
Ответ на | Re: functions vs stored procedures (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: functions vs stored procedures
|
Список | 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 по дате отправления: