Re: Bug in query rewriter - hasModifyingCTE not getting set - Mailing list pgsql-hackers

From Greg Nancarrow
Subject Re: Bug in query rewriter - hasModifyingCTE not getting set
Date
Msg-id CAJcOf-eQDUnHpAeuL3T21u+tvkWqy3XvgPc5Q-FCCFz9a2QSbw@mail.gmail.com
Whole thread Raw
In response to Re: Bug in query rewriter - hasModifyingCTE not getting set  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Bug in query rewriter - hasModifyingCTE not getting set  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

On Wed, Sep 8, 2021 at 8:00 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> "tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com> writes:
> > The attached patch is based on your version.  It includes cosmetic
> > changes to use = instead of |= for boolean variable assignments.
>
> Now, we could potentially make this work if we wrote code to run
> through the copied rtable entries (recursively) and increment the
> appropriate ctelevelsup fields by one.  That would essentially
> have to be a variant of IncrementVarSublevelsUp that *only* acts
> on ctelevelsup and not other level-dependent fields.  That's
> what I meant when I spoke of moving mountains: the amount of code
> that would need to go into this seems out of all proportion to
> the value.  I think we should just throw an error, instead.
> At least till such time as we see actual field complaints.
>

[I don't think Tsunakawa-san will be responding to this any time soon]

I proposed a patch for this issue in a separate thread:
https://www.postgresql.org/message-id/CAJcOf-f68DT=26YAMz_i0+Au3TcLO5oiHY5=fL6Sfuits6r+_w@mail.gmail.com

The patch takes your previously-reverted patch for this issue and adds an error condition, so it does throw an error for that test case in your previous post.
It also affects one existing regression test, since that uses an INSERT...SELECT rule action applied to a command with a data-modifying CTE (and we shouldn't really be allowing that anyway).


Regards,
Greg Nancarrow
Fujitsu Australia

pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Allow escape in application_name (was: [postgres_fdw] add local pid to fallback_application_name)
Next
From: Peter Geoghegan
Date:
Subject: Re: The Free Space Map: Problems and Opportunities