Re: Second RewriteQuery complains about first RewriteQuery in edge case - Mailing list pgsql-hackers

From Bernice Southey
Subject Re: Second RewriteQuery complains about first RewriteQuery in edge case
Date
Msg-id CAEDh4nwrgknRCP1rxJ42PWf+20i2xOBmF-3pNcG5xrqLiKkU2g@mail.gmail.com
Whole thread Raw
In response to Re: Second RewriteQuery complains about first RewriteQuery in edge case  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Second RewriteQuery complains about first RewriteQuery in edge case
List pgsql-hackers
Kirill Reshke <reshkekirill@gmail.com> wrote:
> Added test are good, but two things:
> 1) Why with.sql and not generated.sql ?
This bug is "with" in combination with "generated identity" and
"updatable view". The current fix targets "with", so that made me pick
"with". It should move to "generated_stored" if the fix is idempotent
rewriteTargetListIU.

> 2) Why do you create table and view as temp relations? The bug have
> nothing to do with the temporality of objects?
I copied the other tests in the "with" file, assuming they needed to
be temp. I agree it should be removed.

Dean Rasheed <dean.a.rasheed@gmail.com> wrote:
> Of course, we could attempt to make
> rewriteTargetListIU() idempotent, but that might be more effort
This was my first thought. I still haven't figured my way through how
all the checks work.
This bug doesn't happen on a generated always column that's not
identity, because that follows a different path.

Tom Lane <tgl@sss.pgh.pa.us> wrote:
> How do we know that whatever
> prompted the repeat rewrite didn't change the WITH clauses?
I went through the history and it seemed to me the repeat rewrite was
accidental because of the two ways this method can recurse. Doesn't
mean it's not doing anything.

Thanks, Bernice



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: POC: enable logical decoding when wal_level = 'replica' without a server restart
Next
From: Myles Lewis
Date:
Subject: Re: [PATCH] contrib: Add pg_datemath extension with datediff function