Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> 2010/9/9 Robert Haas <robertmhaas(at)gmail(dot)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

In response to

• Re: returning multiple result sets from a stored procedure at 2010-09-09 20:29:45 from Pavel Stehule

Responses

• Re: returning multiple result sets from a stored procedure at 2010-09-09 21:26:11 from Kevin Grittner
• Re: returning multiple result sets from a stored procedure at 2010-09-09 21:40:40 from Pavel Stehule

pgsql-hackers by date

Next:	From: Kevin Grittner	Date: 2010-09-09 21:26:11
	Subject: Re: returning multiple result sets from a stored procedure
Previous:	From: Darren Duncan	Date: 2010-09-09 21:12:24
	Subject: Re: returning multiple result sets from a stored procedure