|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||"Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>|
|Subject:||Re: Anyone particularly wedded to func_tlist mechanism?|
|Views:||Raw Message | Whole Thread | Download mbox|
"Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)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
|Next Message||Larry Rosenman||2000-08-04 00:57:11||MAC.C (still?)|
|Previous Message||Philip Warner||2000-08-04 00:54:02||pg_dump/restore to convert BLOBs to LZTEXT (optional!)|