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

From Dean Rasheed
Subject Re: Second RewriteQuery complains about first RewriteQuery in edge case
Date
Msg-id CAEZATCV1knAnuji0f0JDR4H=aVdD9pC3a9Zu8E6LqcqKyPbzLw@mail.gmail.com
Whole thread Raw
In response to Re: Second RewriteQuery complains about first RewriteQuery in edge case  (Bernice Southey <bernice.southey@gmail.com>)
List pgsql-hackers
On Thu, 27 Nov 2025 at 14:31, Bernice Southey <bernice.southey@gmail.com> wrote:
>
> 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.

Unfortunately, that means that it suffers from a bug similar to the
original one, but with an INSTEAD OF rule instead of an updatable
view:

---
drop table if exists t1, t2, t3;

create table t1 (a int generated always as identity);
create table t2 (a int);
create table t3 (a int);
create rule t3r as on insert to t3 do instead
  insert into t2 values (new.a) returning *;

with x as (insert into t1 default values returning *)
insert into t3 select * from x;
---

That fails in HEAD and with your patch with the same error as before,
but it works correctly with the v2 patch.

Regards,
Dean



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Partial hash index is not used for implied qual.
Next
From: Sugamoto Shinya
Date:
Subject: Re: [PATCH] Add error hints for invalid COPY options