From: | jian he <jian(dot)universality(at)gmail(dot)com> |
---|---|
To: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: UPDATE with invalid domain constraint |
Date: | 2025-08-20 03:31:52 |
Message-ID: | CACJufxGYwfzK-WH2FKtyaKzUAht_KjimGPzkspc4g5RHoerpmQ@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Aug 19, 2025 at 10:08 PM jian he <jian(dot)universality(at)gmail(dot)com> wrote:
>
> drop table if exists dt1;
> drop domain if exists d1;
> create domain d1 as int;
> create table dt1(i int, c d1);
> insert into dt1 values(1,2);
> alter domain d1 add constraint cc check(value <> 2) not valid;
>
> update dt1 set i = i + 1;
> update dt1 set c = c;
> update dt1 set i = i + 1, c = c;
> update dt1 set i = i + 1, c = c::d1;
>
> Should the four statements above result in an error?
> This only happens with UPDATE, since INSERT will check with domain
> invalid constraints.
the main idea is that
if we find out that a Var Node type is domain with invalid constraint
then we convert the
Var to CoerceToDomain node.
explain (verbose, costs off) update dt1 set i = i + 1;
QUERY PLAN
----------------------------------
Update on public.dt1
-> Seq Scan on public.dt1
Output: (i + 1), c, ctid
(3 rows)
as you can see from the "Output:", column "c" is also here,
In rewriteTargetListIU, In rewriteTargetListIU, I use makeTargetEntry to produce
a new TargetEntry for column c, set its expr to a CoerceToDomain node, and set
resjunk to true.
Attachment | Content-Type | Size |
---|---|---|
v1-0001-UPDATE-with-invalid-domain-constraint.patch | text/x-patch | 8.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | John Naylor | 2025-08-20 03:36:59 | Re: New commitfest app release on August 19th |
Previous Message | Peter Smith | 2025-08-20 02:27:00 | Re: [WIP]Vertical Clustered Index (columnar store extension) - take2 |