Re: Fwd: [JDBC] Weird issues when reading UDT from stored function

Поиск
Список
Период
Сортировка
От Florian Pflug
Тема Re: Fwd: [JDBC] Weird issues when reading UDT from stored function
Дата
Msg-id A7BF4EA6-9385-47B3-B9BC-34649BBD4F6F@phlo.org
обсуждение исходный текст
Ответ на Re: Fwd: [JDBC] Weird issues when reading UDT from stored function  (Oliver Jowett <oliver@opencloud.com>)
Ответы Re: Fwd: [JDBC] Weird issues when reading UDT from stored function  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Lukas Eder
Дата:
Сообщение: Re: Fwd: [JDBC] Weird issues when reading UDT from stored function
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: new clang report