Re: "stored procedures" - use cases?

On Mon, May 9, 2011 at 9:21 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
>
>
> On 05/09/2011 08:20 PM, Bruce Momjian wrote:
>>
>> Tom Lane wrote:
>>>
>>> Peter Eisentraut<peter_e@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?"