Re: [PATCH] no table rewrite when set column type to constrained domain
| От | Viktor Holmberg |
|---|---|
| Тема | Re: [PATCH] no table rewrite when set column type to constrained domain |
| Дата | |
| Msg-id | 2740d5ea-4a7c-4ed8-bcbf-daed0d8d08ad@Spark обсуждение исходный текст |
| Ответ на | Re: [PATCH] no table rewrite when set column type to constrained domain (jian he <jian.universality@gmail.com>) |
| Ответы |
Re: [PATCH] no table rewrite when set column type to constrained domain
|
| Список | pgsql-hackers |
On 23 Mar 2026 at 14:57 +0100, jian he <jian.universality@gmail.com>, wrote:
hi.
https://postgr.es/m/CAEze2Wi4M1grsR0q27etuB-jncJ6qN-1FMdRX-2PkQxcFpM3sQ@mail.gmail.com
Make me realize that ArrayCoerceExpr (one type of array cast to
another type of array) table rewrite is necessary.
For example, the following will cause a table rewrite:
+CREATE TABLE t22(a INT, b INT, c text COLLATE "C", col1 INT[]);
+CREATE DOMAIN domain1 AS INT CHECK(VALUE > 1) NOT NULL;
+CREATE DOMAIN domain2 AS domain1 CHECK(VALUE > 1) NOT NULL;
+CREATE DOMAIN domain6 AS domain2[];
+ALTER TABLE t22 ALTER COLUMN col1 SET DATA TYPE domain6 USING col1;
Now: if the new type is a constrained domain over the old type,
tablescan is enough.
ATColumnChangeRequiresRewrite works just as before.
--
jian
This appears to address some of my comments but not this one?
CREATE DOMAIN domain1 AS INT CHECK(VALUE > 1) NOT NULL;
CREATE TABLE t_const_using(a INT);
INSERT INTO t_const_using VALUES(-2);
ALTER TABLE t_const_using ALTER COLUMN a SET DATA TYPE domain1 USING 5;
SELECT a FROM t_const_using; -- should be 5 after rewrite, not -2
a
----
-2
CREATE DOMAIN domain1 AS INT CHECK(VALUE > 1) NOT NULL;
CREATE TABLE t_const_using(a INT);
INSERT INTO t_const_using VALUES(-2);
ALTER TABLE t_const_using ALTER COLUMN a SET DATA TYPE domain1 USING 5;
SELECT a FROM t_const_using; -- should be 5 after rewrite, not -2
a
----
-2
В списке pgsql-hackers по дате отправления: