From: | Tony Caduto <tony_caduto(at)amsoftwaredesign(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Found small issue with OUT params |
Date: | 2005-09-29 15:17:55 |
Message-ID: | 433C05A3.4000609@amsoftwaredesign.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
>Tony Caduto <tony_caduto(at)amsoftwaredesign(dot)com> writes:
>
>
>>Please don't take this the wrong way, but don't you think even if a
>>single param is declared as OUT it should return the name of the OUT param?
>>
>>
>
>Not really, because "create function foo (in x int, out y float)" is
>supposed to have the same external behavior as "create function foo
>(in x int) returns float". I agree it's a bit of a judgment call, but
>I do not see a case for changing it.
>
> regards, tom lane
>
>
Hi Tom,
I understand where you are coming from, but I really think it should be
changed because that is how every other DB I know of works with a single
OUT param.
I was recently porting a fairly large application from
Firebird/Interbase and I had a bunch of functions that had one output
param, and in the win32 application that I was also moving over, it was
expecting the name of the OUT param, not the name of the function, So
either I change every single instance of the client code to now use the
function name or I add another dummy OUT param so my app does not have
to be modified.
The biggest reason to change this behavior is for porting from other
Databases so client code does not need to be needlessly modifed.
The new IN/OUT/INOUT params are sweet, and aside from this one issue, it
made porting the Firebird procs super easy.
I know I don't have much pull with development, but I think it should be
changed for the 8.1 release.
Thanks,
Tony
From | Date | Subject | |
---|---|---|---|
Next Message | Gaetano Mendola | 2005-09-29 15:24:19 | Re: postgresql clustering |
Previous Message | Luke Lonergan | 2005-09-29 15:17:02 | Re: postgresql clustering |