Re: returning multiple result sets from a stored procedure

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Darren Duncan <darren(at)darrenduncan(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: returning multiple result sets from a stored procedure
Date: 2010-09-09 21:13:32
Message-ID: 6600.1284066812@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Responses

Browse pgsql-hackers by date

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