From: | jian he <jian(dot)universality(at)gmail(dot)com> |
---|---|
To: | Dmitry Koval <d(dot)koval(at)postgrespro(dot)ru> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Add SPLIT PARTITION/MERGE PARTITIONS commands |
Date: | 2025-06-11 04:45:17 |
Message-ID: | CACJufxH3mfNYfHy9+dCUZPhOsmVRtJUJbWU1vH248Lg0eZjhzQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
hi.
we generally no need to worry about the partitioned table check constraint,
generated column does not apply to newly merged partitions.
since partitioned table constraints apply to each individual partition,
including newly created partitions.
However, there are corner cases:
constraints include tableoid column reference.
say pk_1, pk_2 is the partition of pk.
alter table pk add constraint cc check(tableoid <> 18259);
Here, Constraint cc will check whether the tableoid of pk_1 or pk_2 meets the
specified criteria. Similarly, if partitions are merged, the newly merged
partition must also be evaluated against the constraint cc to ensure
it is satisfied.
----------------
The attached patch ensures that the newly merged partition is evaluated against
all of its check constraints and that all stored generated columns are
recomputed, i guess this would be more safe.
Alternatively, we can use pull_varattnos to check whether a constraint or
generated expression contains a reference to the tableoid column.
Attachment | Content-Type | Size |
---|---|---|
v43-0001-MERGE-PARTITIONS-constraint-revalidation.no-cfbot | application/octet-stream | 12.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Hayato Kuroda (Fujitsu) | 2025-06-11 04:48:09 | RE: [PATCH] Proposal: Improvements to PDF stylesheet and table column widths |
Previous Message | Fujii Masao | 2025-06-11 04:33:07 | Re: Extend ALTER DEFAULT PRIVILEGES for large objects |