From: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
---|---|
To: | exclusion(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #17803: Rule "ALSO INSERT ... SELECT ..." fails to substitute default values |
Date: | 2023-02-21 11:56:00 |
Message-ID: | CAEZATCUQtGx6gQtryMbC3ZsEd4GUcc5THVnkXP1F0Fan_uLG-Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Tue, 21 Feb 2023 at 09:21, PG Bug reporting form
<noreply(at)postgresql(dot)org> wrote:
>
> The following queries:
> CREATE TABLE t (a int, b int DEFAULT -1);
> CREATE VIEW v AS SELECT * FROM t;
> CREATE RULE vr AS ON INSERT TO v DO ALSO INSERT INTO t SELECT 1;
> INSERT INTO v VALUES (0, DEFAULT), (1, DEFAULT);
>
> lead to an assert for me:
>
Nice catch.
It looks like we need something like the attached, to deal with
product queries that are INSERT ... SELECT queries. In that case the
VALUES RTE will be at the same index, but in the SELECT part of the
product query, not the top-level product query itself.
Annoyingly, this can't use getInsertSelectQuery(), because the product
query will no longer have the OLD and NEW placeholder entries, so I
have just duplicated the relevant portions of its code, rather than
remove those checks from getInsertSelectQuery().
Regards,
Dean
Attachment | Content-Type | Size |
---|---|---|
fix-default-handling-for-insert-select-rule.patch | text/x-patch | 3.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Duncan Sands | 2023-02-21 12:57:09 | Unlimited memory consumption with long-lived connection |
Previous Message | PG Bug reporting form | 2023-02-21 09:00:01 | BUG #17803: Rule "ALSO INSERT ... SELECT ..." fails to substitute default values |