From: | Gavin Sherry <swm(at)linuxworld(dot)com(dot)au> |
---|---|
To: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Stark <gsstark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Proposal: OUT parameters for plpgsql |
Date: | 2005-03-22 01:57:45 |
Message-ID: | Pine.LNX.4.58.0503221247590.2590@linuxworld.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 22 Mar 2005, Christopher Kings-Lynne wrote:
> >>ANSI SQL allows at most one OUT parameter for a function (which can be
> >>used instead of having the function return a value via the usual means).
> >
> > OK, so that answers my question above: a single OUT parameter should be
> > equated to an ordinary return value, not a RECORD, so as to emulate this
> > aspect of the spec.
>
> Shouldn't you have the spec in one hand while designing this feature? :D
We're miles away from the spec already. For example, the spec requires
that we pass the name of some variable construct, whether it be a host
variable, a transition variable (ie, NEW.foo in the case of a row level
trigger on a table with an attribute foo) or one of a few other less
useful things, for OUT parameters.
I think that not specifying OUT parameters when invoking a function is a
little of confusing but it gives us a lot: its much easier to develop
since we don't have to add a stack of infrastructure for host variables,
for one.
Gavin
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-03-22 02:03:17 | Re: Proposal: OUT parameters for plpgsql |
Previous Message | Tom Lane | 2005-03-22 01:53:32 | Re: Proposal: OUT parameters for plpgsql |