Tom Lane wrote:
> Essentially I'm thinking about the JDBC solution, but automated a bit
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.
In response to
pgsql-hackers by date
|Next:||From: Peter Eisentraut||Date: 2005-02-25 07:02:45|
|Subject: Re: UTF8 or Unicode|
|Previous:||From: Marc G. Fournier||Date: 2005-02-25 06:47:39|
|Subject: Re: 8.0.X and the ARC patent|
pgsql-jdbc by date
|Next:||From: Kovács Péter||Date: 2005-02-25 13:27:49|
|Subject: Statement level transactions|
|Previous:||From: Nico||Date: 2005-02-25 02:00:15|
|Subject: rule/trigger for batch update|