Re: returning multiple result sets from a stored procedure - Mailing list pgsql-hackers

From Tom Lane
Subject Re: returning multiple result sets from a stored procedure
Date
Msg-id 6600.1284066812@sss.pgh.pa.us
Whole thread Raw
In response to Re: returning multiple result sets from a stored procedure  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: returning multiple result sets from a stored procedure  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Re: returning multiple result sets from a stored procedure  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
Pavel Stehule <pavel.stehule@gmail.com> writes:
> 2010/9/9 Robert Haas <robertmhaas@gmail.com>:
>> That seems like a lot of complexity for no real benefit, to me.

> no, you can to specify a expected result type - it's very  for some
> convert or import functions. So we expect so out procedures will
> supports to OUT parameters, then implementation of this mechanism has
> minimal overhead to current implementation. Just to add types of OUT
> parameters to searching algorithm.

It's *not* trivial, not at all.  You are ignoring all of the semantic
implications.  Should foo(IN x int, OUT y int) be considered different
from, and thus allowed to exist at the same time as, foo(IN x int,
OUT y float)?  If so, how do you represent that in the catalogs?
Possibly more to the point, any such decision means that it'll be
impossible to call any stored procedure without fully specifying the
types of output arguments as well as input arguments, else the system
can't tell which procedure you meant to call.  That doesn't sound like
a notational improvement to me.

I'm with Robert: this would be a huge extra complication for a
remarkably small amount of benefit.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Darren Duncan
Date:
Subject: Re: returning multiple result sets from a stored procedure
Next
From: "Kevin Grittner"
Date:
Subject: Re: returning multiple result sets from a stored procedure