Re: BUG #18502: Upsert on view returns 42P10 error when condition is an expression
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: michael.wanghai.a@outlook.com
Cc: Peter Geoghegan <pg@bowt.ie>, pgsql-bugs@lists.postgresql.org
Date: 2024-06-11T20:54:31Z
Lists: pgsql-bugs
Attachments
- adjust-varnos-in-infer_arbiter_indexes.patch (text/x-diff) patch
PG Bug reporting form <noreply@postgresql.org> writes:
> I have a table, index and view like following:
> ```
> CREATE TABLE my_table
> (
> id uuid primary key,
> data jsonb not null
> );
> CREATE UNIQUE INDEX ON my_table ((data ->> 'key'));
> CREATE VIEW my_view AS SELECT * FROM my_table;
> ```
> The upsert on view returns 42P10 error when I execute the following SQL
> ```
> INSERT INTO my_view (id, data)
> VALUES ('990cc75c-2e60-4c0d-8bec-9ac976dc03bc'::uuid,
> '{
> "key": "value"
> }'::jsonb)
> ON CONFLICT ((data ->> 'key'))
> DO NOTHING;
> ```
For the archives' sake: the error being complained of is
ERROR: there is no unique or exclusion constraint matching the ON CONFLICT specification
Thanks for the report. The fault lies with infer_arbiter_indexes(),
which assumes that it can match the output of
RelationGetIndexExpressions or RelationGetIndexPredicate
directly to the query without adjusting varnos. That works
most of the time, because the INSERT target typically has
varno 1, matching the way these trees are stored in the catalogs.
But not so much when we've flattened an updatable view;
so the match fails even when it should succeed.
The attached seems to be enough to fix it.
regards, tom lane
Commits
-
Fix infer_arbiter_indexes() to not assume resultRelation is 1.
- b188e1bf7576 16.4 landed
- 9256bf6eb35a 12.20 landed
- 915de706d28c 17.0 landed
- 5e8aa32a9ce7 13.16 landed
- 1d0399b54068 15.8 landed
- 096f2132c66c 14.13 landed