Re: COnsidering a move away from Postgres - Mailing list pgsql-general

From Tom Lane
Subject Re: COnsidering a move away from Postgres
Date
Msg-id 18544.1120141211@sss.pgh.pa.us
Whole thread Raw
In response to COnsidering a move away from Postgres  (Jason Tesser <jtesser@nbbc.edu>)
Responses Re: COnsidering a move away from Postgres
Re: COnsidering a move away from Postgres
Re: COnsidering a move away from Postgres
List pgsql-general
Jason Tesser <jtesser@nbbc.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-PARAMETERS
http://developer.postgresql.org/docs/postgres/plpgsql-declarations.html#PLPGSQL-DECLARATION-ALIASES
http://developer.postgresql.org/docs/postgres/plpgsql-control-structures.html#PLPGSQL-STATEMENTS-RETURNING

> 2. Also with stored procs it is painful to return mulitple records. The syntax
> is more complicated than some other databases.  (We are currently using
> PL/SQL)

What's so hard about RETURN NEXT?  What would you rather have?

> 3. The tools.  PgAdmin does some things well but it is lacking the features of
> some of the other gui tools.

I'm sure the pgAdmin guys would love having some more help.

            regards, tom lane

pgsql-general by date:

Previous
From: David Gagnon
Date:
Subject: Re: Explain Analyse never returns .. maybe a bug
Next
From: Ajay Dalvi
Date:
Subject: Error while installing Slony 1.1.0 for PostGreSql version 7.3.4