Peifeng Qiu <pg...@qiupf.dev> writes:
>> the need for this code seems not that great. But as to the code itself I'm
>> unable to properly judge.
> A simplified version of my use case is like this:
> CREATE FOREIGN TABLE ft(rawdata json);
> INSERT INTO tbl SELECT (convert_func(rawdata)).* FROM ft;
It might be worth noting that the code as we got it from Berkeley
could do this scenario without multiple evaluations of convert_func().
Memory is foggy, but I believe it involved essentially a two-level
targetlist. Unfortunately, the scheme was impossibly baroque and
buggy, so we eventually ripped it out altogether in favor of the
multiple-evaluation behavior you see today. I think that commit
62e29fe2e might have been what ripped it out, but I'm not quite
sure. It's about the right time-frame, anyway.
I mention this because trying to reverse-engineer this situation
in execExpr seems seriously ugly and inefficient, even assuming
you can make it non-buggy. The right solution has to involve never
expanding foo().* into duplicate function calls in the first place,
which is the way it used to be. Maybe if you dug around in those
twenty-year-old changes you could get some inspiration.
I tend to agree with David that LATERAL offers a good-enough
solution in most cases ... but it is annoying that we accept
this syntax and then pessimize it.
regards, tom lane
