On Feb16, 2011, at 13:43 , Oliver Jowett wrote:
> Anyway, it's a bit counterintuitive that
> SELECT * FROM f($1,$2) AS RESULT
> where f() takes two OUT parameters always returns two columns, but
> SELECT * FROM f($1) AS RESULT
> might return any number of columns! Is that really the correct behavior
Hm, I've browsed through the code and it seems that the current behaviour
was implemented on purpose.
build_function_result_tupdesc_d() in funcapi.c explicitly does
* If there is no output argument, or only one, the function does not
* return tuples.
if (numoutargs < 2)
and examine_parameter_list() in functioncmds.c takes care to set
requiredResultType to RECORDOID only if there is more than one OUT
parameter, otherwise it gets set to the (one) OUT parameter's type.
Might make sense to check the list archives, maybe there is something
there that elucidates the reasoning behind this...
In response to
pgsql-hackers by date
|Next:||From: Bruce Momjian||Date: 2011-02-16 13:40:51|
|Subject: Re: new clang report|
|Previous:||From: Greg Smith||Date: 2011-02-16 13:15:41|
|Subject: Re: [PERFORM] pgbench to the MAXINT|
pgsql-jdbc by date
|Next:||From: Tom Lane||Date: 2011-02-16 15:23:43|
|Subject: Re: Fwd: [JDBC] Weird issues when reading UDT from stored function |
|Previous:||From: Oliver Jowett||Date: 2011-02-16 12:43:09|
|Subject: Re: Fwd: [JDBC] Weird issues when reading UDT from stored