Re: Second RewriteQuery complains about first RewriteQuery in edge case

Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> wrote:
> Yes, I think that would work, but I think a simpler solution would be
> to just have RewriteQuery() track which CTEs it had already rewritten,
> which can be done just by passing around a list of CTE names.
> Something like the attached.
I was playing around with an idea I had based on my first attempt to
fix this, when I got your email.

FWIW, I think I found a way to fix my bug that doesn't break your
rules example. I added a bool to RewriteQuery, and used this to stop
reprocessing updatable view CTEs. This leaves the rules recursion path
unchanged. Which means rule CTEs might still be processed repeatedly.
But as they probably can't be data-modifiable, I think
rewriteTargetListIU is effectively idempotent? The advantage of your
approach is it's consistent for all views, and it doesn't rely on
improbable data-modifiability for idempotency. Plus I'm still very
uncertain if there's more traps in rules I'm unaware of.

I also took another look at rewriteTargetListIU. From what I can make
out, stored generated columns rely on SetToDefault for idempotency.
But identity can't use this, so this is why a change to querytree
could be needed?

Thanks, Bernice