Kyotaro HORIGUCHI wrote:
> tgl> The problem is that joining isn't the only way that such expansion
> tgl> can happen. Set-returning functions in the targetlist are another
> tgl> way, and I'm not sure that there aren't others. Here's an example
> tgl> that I'm pretty sure breaks your patch (though I didn't actually
> tgl> reinstall the patch to try it):
> tgl> Also, even if the row-expansion mechanism is a join, it's certainly
> tgl> insufficient to check that the lower-order sort column is an
> tgl> expression in variables of the index's table. Something like "f2 +
> tgl> random()" is going to need an explicit sort step anyway.
> tgl> These particular objections could be worked around by checking for
> tgl> set-returning functions and volatile functions in the lower-order
> tgl> ORDER BY expressions. But I have to say that I think I'm losing
> tgl> faith in the entire idea. I have little confidence that there
> tgl> aren't other cases that will break it.
> On the other hand, the precondition should be satisfied when all extended
> columns are simple Vars of the target table. I believe Vars cannot produce
> multiple result. More close checking for every possibility could be done
> but it should be a overdone.
> The following modification to v7 does this.
It seems to me that this would be reasonable at least as the first step and
that it would be better to leave more close checking for future work.
Thanks,
Best regards,
Etsuro Fujita
