From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | ALTER COLUMN TYPE vs. domain constraints |
Date: | 2017-10-27 18:15:30 |
Message-ID: | 30656.1509128130@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I found out that altering a column's type does not play nicely with
domain constraints: tablecmds.c expects that only table constraints
could depend on a column. Now, it's easy to hit that with domains
over composite, so I propose to fix it in HEAD with the attached
patch. However, if you really work at it, you can make it fail
in the back branches too:
regression=# create type comptype as (r float8, i float8);
CREATE TYPE
regression=# create domain silly as float8 check ((row(value,0)::comptype).r > 0);
CREATE DOMAIN
regression=# alter type comptype alter attribute r type varchar;
ERROR: cache lookup failed for relation 0
Before commit 6784d7a1d, the ALTER actually went through, leaving a
mess. Fortunately it doesn't actually crash afterwards, but you
get things like
regression=# select 0::silly;
ERROR: ROW() column has type double precision instead of type character varying
We could consider back-patching the attached to cover this, but
I'm not entirely sure it's worth the trouble, because I haven't
thought of any non-silly use-cases in the absence of domains
over composite. Comments?
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
handle-domain-constraints-when-altering-column-type.patch | text/x-diff | 12.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Cristiano Coelho | 2017-10-27 18:48:08 | pg_trgm word_similarity inconsistencies or bug |
Previous Message | Alvaro Herrera | 2017-10-27 17:27:30 | Re: Proposal: Local indexes for partitioned table |