2011/5/10 Bruce Momjian <br...@momjian.us>: > 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. >
no - you are little bit confused :). CALL and function execution shares nothing. There is significant differences between function and procedure. Function is called only from executor - from some plan, and you have to know a structure of result before run. The execution of CALL is much simple - you just execute code - without plan and waiting for any result - if there is. > 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. > We can use a SETOF cursors for returning a multiple result sets now. But there are a few complications: a) The client should to wait for finish of all sets from multiple result sets - minimally in PL/pgSQL b) client 'psql' doesn't support a unpacking result when result is multiple result set c) The using cursors isn't too comfortable - in comparation to MS SQL or MySQL Regards Pavel > -- > 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 > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
