Tom Lane wrote:
> Essentially I'm thinking about the JDBC solution, but automated a bit
> better.
So would your proposal invent a new "stored procedure" construct, or
just add some sugar to the existing function stuff? i.e. will you be
able to issue a CREATE FUNCTION that specifies OUT parameters?
> This doesn't address the question of SETOF results, of course. I'm
> leaning towards returning those as cursors.
This is part of the reason I liked the approach of introduced SQL-level
variables. Besides being a feature that has some use in itself, it could
be extended reasonably cleanly to allow (effectively) SETOF variables
and rowtype variables.
> Well, I think that when people ask us for "stored procedures", most of
> them mean that they want transaction control.
Yes, that is certainly what Gavin and I spent most of our time banging
our heads against the wall on :(
> But if you can pass over what you have, I'd like to see about
> pressing forward.
Sure, I've attached a very WIP patch with the utility command
definitions; unfortunately I don't think it will be of much use, as much
of it is CREATE PROCEDURE-related boilerplate. Gavin will update the
matching-arguments-by-name code to HEAD at some point in the future; I
believe that works fine for functions (since we just error out in case
of ambiguity), so we can include it in 8.1 independently on any other
work on SPs.
-Neil