From: | Chris Bitmead <chrisb(at)nimrod(dot)itg(dot)telstra(dot)com(dot)au> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Anyone particularly wedded to func_tlist mechanism? |
Date: | 2000-08-04 00:21:28 |
Message-ID: | 398A0C88.A7769776@nimrod.itg.telecom.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Hiroshi Inoue | 2000-08-04 00:43:50 | RE: Anyone particularly wedded to func_tlist mechanism? |
Previous Message | Hiroshi Inoue | 2000-08-04 00:02:33 | RE: Raw constraint & pg_relcheck.rcsrc |