Re: Fwd: [JDBC] Weird issues when reading UDT from stored function - Mailing list pgsql-hackers

From Florian Pflug
Subject Re: Fwd: [JDBC] Weird issues when reading UDT from stored function
Date
Msg-id A7BF4EA6-9385-47B3-B9BC-34649BBD4F6F@phlo.org
Whole thread Raw
In response to Re: Fwd: [JDBC] Weird issues when reading UDT from stored function  (Oliver Jowett <oliver@opencloud.com>)
Responses Re: Fwd: [JDBC] Weird issues when reading UDT from stored function  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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
> here?


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)
    return NULL;

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...

best regards,
Florian Pflug

pgsql-hackers by date:

Previous
From: Lukas Eder
Date:
Subject: Re: Fwd: [JDBC] Weird issues when reading UDT from stored function
Next
From: Bruce Momjian
Date:
Subject: Re: new clang report