Skip site navigation (1) Skip section navigation (2)

Re: Anyone particularly wedded to func_tlist mechanism?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Anyone particularly wedded to func_tlist mechanism?
Date: 2000-08-04 00:55:15
Message-ID: 28002.965350515@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
"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

In response to

Responses

pgsql-hackers by date

Next:From: Larry RosenmanDate: 2000-08-04 00:57:11
Subject: MAC.C (still?)
Previous:From: Philip WarnerDate: 2000-08-04 00:54:02
Subject: pg_dump/restore to convert BLOBs to LZTEXT (optional!)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group