| From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> | 
|---|---|
| To: | Peter Eisentraut <peter(at)eisentraut(dot)org> | 
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> | 
| Subject: | Re: Catalog domain not-null constraints | 
| Date: | 2023-11-23 16:38:30 | 
| Message-ID: | 202311231638.httd7tqo45ux@alvherre.pgsql | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
On 2023-Nov-23, Peter Eisentraut wrote:
> This patch set applies the explicit catalog representation of not-null
> constraints introduced by b0e96f3119 for table constraints also to domain
> not-null constraints.
I like the idea of having domain not-null constraints appear in
pg_constraint.
> Since there is no inheritance or primary keys etc., this is much simpler and
> just applies the existing infrastructure to domains as well.
If you create a table with column of domain that has a NOT NULL
constraint, what happens?  I mean, is the table column marked
attnotnull, and how does it behave?  Is there a separate pg_constraint
row for the constraint in the table?  What happens if you do
ALTER TABLE ... DROP NOT NULL for that column?
-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/
"Por suerte hoy explotó el califont porque si no me habría muerto
 de aburrido"  (Papelucho)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tomas Vondra | 2023-11-23 16:45:34 | Re: undetected deadlock in ALTER SUBSCRIPTION ... REFRESH PUBLICATION | 
| Previous Message | Alvaro Herrera | 2023-11-23 16:35:25 | Re: Catalog domain not-null constraints |