Re: Anyone particularly wedded to func_tlist mechanism? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Anyone particularly wedded to func_tlist mechanism?
Date
Msg-id 28002.965350515@sss.pgh.pa.us
Whole thread Raw
In response to RE: Anyone particularly wedded to func_tlist mechanism?  ("Hiroshi Inoue" <Inoue@tpf.co.jp>)
Responses RE: Anyone particularly wedded to func_tlist mechanism?
List 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 by date:

Previous
From: Philip Warner
Date:
Subject: pg_dump/restore to convert BLOBs to LZTEXT (optional!)
Next
From: Larry Rosenman
Date:
Subject: MAC.C (still?)