Re: Proposal: OUT parameters for plpgsql

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Proposal: OUT parameters for plpgsql
Date: 2005-03-22 04:20:19
Message-ID: 87d5tscnwc.fsf@stark.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> > I would have expected the return value to be an extra column added to the
> > record.
>
> I'd prefer not to do that, because having a "return type" that's
> different from the true return type of the function (ie the RECORD)
> is going to cause untold amounts of confusion.

Yes, I can see that angle. I was just thinking that since the whole point of
this exercise was to achieve some compatibility with a specific interface that
your hands were going to be tied.

But that other point about other systems only allowing IN or INOUT on
procedures where normal return values aren't allowed at all seems to resolve
that issue.

--
greg

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Neil Conway 2005-03-22 05:56:31 locks in CREATE TRIGGER, ADD FK
Previous Message Christopher Kings-Lynne 2005-03-22 03:37:58 Using new copy libpq functions on a v2 protocol backend