On Mon, May 9, 2011 at 9:21 PM, Andrew Dunstan <and...@dunslane.net> wrote: > > > On 05/09/2011 08:20 PM, Bruce Momjian wrote: >> >> Tom Lane wrote: >>> >>> Peter Eisentraut<pete...@gmx.net> writes: >>>> >>>> On mån, 2011-04-25 at 14:35 -0500, Kevin Grittner wrote: >>>>> >>>>> (1) All the \d commands in psql should be implemented in SPs so >>>>> that they are available from any client, through calling one SP >>>>> equivalent to one \d command. >>>> >>>> You don't need stored procedures with special transaction behavior for >>>> this. >>> >>> No, but what you *would* need is the ability to return multiple result >>> sets from one call. Even then, you could not exactly duplicate the >>> current output of \d; but you could duplicate the functionality. >> >> Oh, good point. Thanks. > > 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. -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?" -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers