Обсуждение: Anyone particularly wedded to func_tlist mechanism?
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
> 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. I totally agree. That structure is very confusing, and it is hard to know what they mean. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
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
> -----Original Message----- > From: Tom Lane > > 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. I don't understand details about current fmgr changes,sorry. If I remember correctly,this has been only in case of SQL functions. In addition,SQL functions has returned a TupleTableSlot not a tuple if the return type is a compound type. Has it been changed already ? Or would it be changed ? Regards. Hiroshi Inoue Inoue@tpf.co.jp
"Hiroshi Inoue" <Inoue@tpf.co.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
> -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > > "Hiroshi Inoue" <Inoue@tpf.co.jp> writes: > > > 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. > I see. Fieldselect node could expect to see the tuple descriptor used to store the HeapTuple. BTW,AFAIK PL/pgSQL functions return a HeapTuple directly. Regards. Hiroshi Inoue Inoue@tpf.co.jp
Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:
> 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.
AFAICS what I have in mind doesn't affect that one way or the other.
The main problem you'll have to deal with is the tension between single
values and sets. If you try it now with the regression database:
regression=# SELECT p.name, p.hobbies.name, p.hobbies.equipment.name FROM ONLY
person p;name | name | name
-------+-------------+---------------mike | posthacking | advilmike | posthacking | peet's coffeejoe | basketball
|hightopssally | basketball | hightops
(4 rows)
regression=# SELECT p.name, p.hobbies.name, p.hobbies.equipment.name FROM ONLY
regression-# person p where p.hobbies.equipment.name = 'hightops';
ERROR: An operand to the '=' operator returns a set of text, but '=' takes single values, not sets.
This is not just the parser being unreasonably picky: it's protecting
execQual.c, which has no idea what to do with set-valued qual
expressions.
regards, tom lane