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
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 |