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
spdevel-2.patch.gz
Description: application/gzip
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
