Horton

Re: Catalog domain not-null constraints

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter@eisentraut.org>
Cc: jian he <jian.universality@gmail.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, pgsql-hackers <pgsql-hackers@postgresql.org>, vignesh C <vignesh21@gmail.com>, Aleksander Alekseev <aleksander@timescale.com>
Date: 2024-02-11T21:42:44Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix ALTER DOMAIN NOT NULL syntax

  2. Catalog domain not-null constraints

  3. Add tests for domain-related information schema views

Peter Eisentraut <peter@eisentraut.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