Andrei Lepikhov <lepihov@gmail.com> writes:
> On 19/8/2024 18:36, Tom Lane wrote:
>> This seems like it's making assumptions it shouldn't about what
>> CustomScan does. If there's an argument for doing this, it should
>> be added to the adjacent comments.
> Hm, I got into this problem many times using CustomScan node. Do you
> have some objections to not allow CustomScan node have a RECORD Var in
> the target list?
In the case of a childless Result, we can suppose that the reason why
we're here is that a provably-empty subquery got optimized away.
If the Var were actually evaluated at runtime, it would fail, so that
had better be the case. (I thought about extending these new Asserts
to check that the Result has a constant-false resconstantqual, but
decided that was overkill.)
It's not clear to me what the equivalent argument is for allowing
CustomScan. I don't say that there isn't one. I do say that a patch
like this should make that argument, in the same comment block that
explains why we're doing this for Result.
The main reason I'm being sticky about this is that if we need to
allow CustomScan, then it seems likely that we also need to allow
ForeignScan, and maybe some other things, and then I start to
wonder if we should have any assertion at all about the child
plan type. So I want to actually understand what is the scenario
in which this will happen.
regards, tom lane
