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.
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 |