Re: Anyone particularly wedded to func_tlist mechanism?

At some stage I'd like to be able to query fields by odbms style
navigation. Like select * from person where person.garage.car.colour =
'red'. Just keep that in mind with any change you do.

Tom Lane wrote:
>
> 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.
>
> Comments?
>
> regards, tom lane