Re: BUG #17633: Define rule on views which do insert to another relation trigger cache lookup failed error.

From: Japin Li <japinli(at)hotmail(dot)com>
To: Richard Guo <guofenglinux(at)gmail(dot)com>
Cc: jiye_sw(at)126(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #17633: Define rule on views which do insert to another relation trigger cache lookup failed error.
Date: 2022-10-11 14:35:50
Message-ID: MEYP282MB1669B5146A97FCD8D18A75EFB6239@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs


On Tue, 11 Oct 2022 at 21:16, Richard Guo <guofenglinux(at)gmail(dot)com> wrote:
> On Tue, Oct 11, 2022 at 8:29 PM Japin Li <japinli(at)hotmail(dot)com> wrote:
>
>>
>> On Tue, 11 Oct 2022 at 20:09, Richard Guo <guofenglinux(at)gmail(dot)com> wrote:
>>
>> Yeah, I also notice this, attch a patch to fix it.
>
>
> +1 for the idea. We need to identify the right target relation for each
> product query and rt_entry_relation is not the right one.
>

After some more thinking, I find the previous cannot work correctly.
For example:

CREATE OR REPLACE v1_r AS ON INSERT TO t1 DO ALSO SELECT * FROM t2;

> A minor comment is can we know the product query is not CMD_SELECT?
> If so I suggest we add an assertion before fetching the target relation,
> something like:
>
> Assert(pt->resultRelation != 0);
>

Oh, I think this might not be true. The product query comes from rules,
which might be a SELECT query, IIUC. See above example.

--
Regrads,
Japin Li.
ChengDu WenWu Information Technology Co.,Ltd.

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2022-10-11 14:58:19 Re: BUG #17634: Inconsistent view_definition in information_schema.views
Previous Message PG Bug reporting form 2022-10-11 13:32:03 BUG #17634: Inconsistent view_definition in information_schema.views