Re: Anyone particularly wedded to func_tlist mechanism?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Anyone particularly wedded to func_tlist mechanism?
Дата
Msg-id 28002.965350515@sss.pgh.pa.us
обсуждение исходный текст
Ответ на RE: Anyone particularly wedded to func_tlist mechanism?  ("Hiroshi Inoue" <Inoue@tpf.co.jp>)
Ответы RE: Anyone particularly wedded to func_tlist mechanism?  ("Hiroshi Inoue" <Inoue@tpf.co.jp>)
Список pgsql-hackers
"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
>> The "target list" that's added to function-call nodes in expressions
>> has bugged me for a long time, because it seems to clutter expression
>> trees quite a bit (thus wasting space in stored rules, for example)
>> without really being used for much.

> If I remember correctly,this has been only in case of SQL functions.

True, the tlist is ignored except in SQL functions --- another reason
why attaching it to all function nodes is a waste.  I believe that's
itself a bug, since it seems like PL functions ought to be capable
of returning tuples (whether they actually can or not is another story,
but it sure seems like plpgsql ought to be close to being able to).
By separating the fieldselect operation into another node, we can fix
that bug too, since it wouldn't matter what the function's
implementation language is.

> In addition,SQL functions has returned a TupleTableSlot not a tuple
> if the return type is a compound type.

Right, the Datum representation of a tuple type is a pointer to a
TupleTableSlot, so that's what this new FieldSelect node would expect
to see at runtime.  I don't see any need to change that.
        regards, tom lane


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

Предыдущее
От: Philip Warner
Дата:
Сообщение: pg_dump/restore to convert BLOBs to LZTEXT (optional!)
Следующее
От: Larry Rosenman
Дата:
Сообщение: MAC.C (still?)