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.
I've now dug around and determined that the only thing it is used for
is selecting out a single field from a function that returns a tuple.
For example, if you have a function-returning-tuple f(x), you can select
out field f1 from its result with "x.f.f1" (in the rather bogus notation
PG uses for this). In functions that return simple datatypes, the
tlist is a complete waste of space.
It seems to me that this design is completely bogus --- for one thing,
it's silly to restrict the notion of field-selection to be done only in
the context of a function call.
I propose removing the tlist from function-call nodes. To handle field
selection, we should instead invent a separate "FieldSelect" expression
operator that is applied to the result of the function call, or perhaps
someday other kinds of expressions that can return tuples. Aside from
saving space, we'll be able to cleanly represent both the result type of
the function (ie, the tuple datatype) and the type of the field (which
will be the result of the FieldSelect node). Right now there's only one
node field that represents the result type of the function call, so we
can't remember the actual result type of the function call itself.
BTW, the same remarks apply to Param node tlists.
regards, tom lane
pgsql-hackers by date
|Next:||From: Bruce Momjian||Date: 2000-08-03 23:22:40|
|Subject: Re: Anyone particularly wedded to func_tlist mechanism?|
|Previous:||From: Mark Hollomon||Date: 2000-08-03 20:23:56|
|Subject: Re: Toasting more system-table columns|