Martijn van Oosterhout wrote:
>On Fri, Sep 30, 2005 at 10:20:34AM -0500, Tony Caduto wrote:
>
>
>>Tom,
>>I hardly think the overhead would be significant on modern processors, I
>>don't think the majority of users are running on Pentium 90s.( I am
>>assuming you mean a performance overhead)
>>
>>
>
>Um, please read the documention. Returning a tuple is *significantly*
>more expensive than returning a single value. You have to get the tuple
>descriptor, allocate memory for the tuple, fill in all the fields with
>your data... For a single value you just return it.
>
>See here for all the details, you really don't want to do it if you
>don't need to.
>
>http://www.postgresql.org/docs/8.0/interactive/xfunc-c.html#AEN30497
>
>Now, you could fudge the parser to automatically alter the name of the
>value in the function but I'm have no idea how hard that would be...
>
>
So you might notice little performance hit bringing back a million rows,
and most of these type of single OUT params functions only return one
row/value anyway.
There would be zero perceivable difference in performance regardless of
the extra overhead for a single value/row.
As a application developer, I don't care about tuples etc, I just want
it to work as expected without having to
resort to hacks like creating a second OUT param that is not used,
otherwise I would have to change a lot of client code where ever the OUT
param is refernced by name instead of position and that is done a lot
because the position is more likely to change than the name.
The bottom line(regardless of any overhead or if I read the docs about
returning a tuple) is that if you have a OUT param it should return that
name, not the name of the function, period.
Thanks,
Tony
