Re: UNNEST with multiple args, and TABLE with multiple funcs

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: UNNEST with multiple args, and TABLE with multiple funcs
Дата
Msg-id 24073.1385149651@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: UNNEST with multiple args, and TABLE with multiple funcs  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Список pgsql-hackers
Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
>  Tom> Well, it's not insane on its face.  The rowtype of f in the
>  Tom> first example is necessarily a built-on-the-fly record, but in
>  Tom> the second case using the properties of the underlying named
>  Tom> composite type is possible, and consistent with what happens in
>  Tom> 9.3 and earlier.  (Not that I'm claiming we were or are totally
>  Tom> consistent ...)

> Right, but your changes to the code make it look like there was an
> intended change there - with the scan type tupdesc being forced to
> RECORD type and its column names changed.

I did set things up so that if you have a RECORD result, the column names
will be those of the query's alias list; this was in response to the
comment in the patch that complained that we were inconsistent about where
we were getting the names from if you had a mix of named-composite
functions and other functions.  I believe what is happening in the case
you show is that the function is returning a composite Datum that's marked
with the composite type's OID, and the upstream consumers are looking at
that, not at the scan tupdesc.  I'm not really excited about tracing down
exactly what the data flow is ...
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Replication Node Identifiers and crashsafe Apply Progress
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Replication Node Identifiers and crashsafe Apply Progress