Anyone particularly wedded to func_tlist mechanism?
От | Tom Lane |
---|---|
Тема | Anyone particularly wedded to func_tlist mechanism? |
Дата | |
Msg-id | 24022.965340919@sss.pgh.pa.us обсуждение исходный текст |
Ответы |
Re: Anyone particularly wedded to func_tlist mechanism?
RE: Anyone particularly wedded to func_tlist mechanism? |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: