From: | jian he <jian(dot)universality(at)gmail(dot)com> |
---|---|
To: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | [PATCH] no table rewrite when set column type to constrained domain |
Date: | 2025-07-09 18:00:15 |
Message-ID: | CACJufxFX0DupbF5+DBNF3mXCFNTZ1Y7jpT11+tCD_FcyADHs2A@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
hi.
the attached patch is to implement the $subject feature.
i was mainly intrigued by the discussion in
https://www.postgresql.org/message-id/20190226061450.GA1665944@rfd.leadboat.com
the main gotcha is struct NewColumnValue.
we do ``palloc0(sizeof(NewColumnValue));`` in ATExecAddColumn,
ATExecSetExpression, ATPrepAlterColumnType.
ATExecAddColumn: Adding a new column with domain with constraints will cause
table rewrite.
ATExecSetExpression: for stored generated column will cause table rewrite, we do
not support domain over virtual generated columns now.
ATPrepAlterColumnType: we only do table rewriting occasionally.
see ATColumnChangeRequiresRewrite.
If table rewrite is required, then there is nothing we can do. so
we only need to focus on ATPrepAlterColumnType.
we can add a new boolean field, coerce_to_domain, to NewColumnValue. this field
is set to true only when changing an existing column's type to a constrained
domain. In such cases, a table scan is enough—no table rewrite is needed.
coerce_to_domain will set to false, if table rewrite is required.
Attachment | Content-Type | Size |
---|---|---|
v1-0001-no-table-rewrite-when-set-column-type-to-constrained-domain.patch | text/x-patch | 11.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2025-07-09 18:13:08 | Re: [PoC] Federated Authn/z with OAUTHBEARER |
Previous Message | Jacob Champion | 2025-07-09 17:59:47 | Re: [PoC] Federated Authn/z with OAUTHBEARER |