Re: Second RewriteQuery complains about first RewriteQuery in edge case
| От | Dean Rasheed |
|---|---|
| Тема | Re: Second RewriteQuery complains about first RewriteQuery in edge case |
| Дата | |
| Msg-id | CAEZATCV1knAnuji0f0JDR4H=aVdD9pC3a9Zu8E6LqcqKyPbzLw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Second RewriteQuery complains about first RewriteQuery in edge case (Bernice Southey <bernice.southey@gmail.com>) |
| Список | 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 по дате отправления: