Re: COnsidering a move away from Postgres

On Thu, 2005-06-30 at 10:18 -0500, Jason Tesser wrote:
> HI
>
> On Thursday 30 June 2005 9:20 am, Tom Lane wrote:
> > Jason Tesser <jtesser(at)nbbc(dot)edu> writes:
> > > 1. Our dev plan involves alot of stored procedures to be used and we have
> > > found the way this is done in PG to be painful. (ie. To return multiple
> > > record from different tables you have to define a type.
> >
> > FWIW, this won't be essential any more in 8.1. See the examples in the
> > development documentation:
> > http://developer.postgresql.org/docs/postgres/xfunc-sql.html#XFUNC-OUTPUT-P
> >ARAMETERS
> > http://developer.postgresql.org/docs/postgres/plpgsql-declarations.html#PLP
> >GSQL-DECLARATION-ALIASES
> > http://developer.postgresql.org/docs/postgres/plpgsql-control-structures.ht
> >ml#PLPGSQL-STATEMENTS-RETURNING
>
> I might be missing it but how does this help me. What I would like is to be
> able to return multiple records from a select statement that return multiple
> columns from different tables without having to create a type. This is why
> it is painful for us. The management of types is bad because as far as I
> know there is no alter type and the depencies become a nightmane if you ever
> need to change something.
>
>
If I understand the new features correctly, rather than:
CREATE FUNCTION foo(i int) RETURNS custom_type AS ....
and custom_type is (int,text,text)
you will be able to do the following instead:
CREATE FUNCTION foo(IN i int, OUT x int, OUT y text, OUT z text) AS ...

As far as hard coding the OUT datatypes, if I understand the docs
correctly you can even:
CREATE FUNCTION foo(IN i int, OUT x anyelement, OUT y anyelement, OUT z
anyelement) AS ...

No custom type needed .. you specify how the output format in the
argument section itself.

Sven