Re: Found small issue with OUT params - Mailing list pgsql-hackers

From Tony Caduto
Subject Re: Found small issue with OUT params
Date
Msg-id 433C05A3.4000609@amsoftwaredesign.com
Whole thread Raw
In response to Re: Found small issue with OUT params  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:

>Tony Caduto <tony_caduto@amsoftwaredesign.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





pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [DOCS] Added documentation about caching, reliability
Next
From: Gaetano Mendola
Date:
Subject: Re: postgresql clustering