Re: BUG #17803: Rule "ALSO INSERT ... SELECT ..." fails to substitute default values

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

In response to

Responses

Browse pgsql-bugs by date

  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