| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
| Cc: | jian he <jian(dot)universality(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, vignesh C <vignesh21(at)gmail(dot)com>, Aleksander Alekseev <aleksander(at)timescale(dot)com> |
| Subject: | Re: Catalog domain not-null constraints |
| Date: | 2024-02-11 21:42:44 |
| Message-ID: | 2063822.1707687764@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Peter Eisentraut <peter(at)eisentraut(dot)org> writes:
> But I see that table constraints do not work that way. A command like
> ALTER TABLE t1 ADD NOT NULL c1 does nothing if the column already has a
> NOT NULL constraint. I'm not sure this is correct. At least it's not
> documented. We should probably make the domains feature work the same
> way, but I would like to understand why it works that way first.
That's probably a hangover from when the underlying state was just
a boolean (attnotnull). Still, I'm a little hesitant to change the
behavior. I do agree that named constraints need to "stack", so
that you'd have to remove each one before not-nullness stops being
enforced. Less sure about unnamed properties.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Munro | 2024-02-11 22:25:53 | Re: gai_strerror() is not thread-safe on Windows |
| Previous Message | Peter Eisentraut | 2024-02-11 21:10:10 | Re: Catalog domain not-null constraints |