Christopher Browne wrote: > > Multiple resultsets in one call would be a good thing, though, no? > > > > cheers > > I *thought* the purpose of having stored procedures was to allow a > substrate supporting running multiple transactions, so it could do > things like: > - Managing vacuums > - Managing transactions > - Replacing some of the need for dblink. > - Being an in-DB piece that could manage LISTENs > > It seems to be getting "bikeshedded" into something with more > "functional argument functionality" than stored functions. > > I think we could have a perfectly successful implementation of "stored > procedures" that supports ZERO ability to pass arguments in or out. > That's quite likely to represent a good start.
I am kind of confused too, particularly with the CALL syntax. I thought our function call usage was superior in every way to CALL, so why implement CALL? I assume for SQL-standards compliance, right? Does multiple result sets require CALL? I assume autonomous transactions don't require CALL. Are we assuming no one is going to want a function that allows multiple result sets or autonomous transactions? That seems unlikely. I would think CALL is independent of those features. Maybe we need those features to support SQL-standard CALL, and we will just add those features to functions too. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
