Horton

Re: cataloguing NOT NULL constraints

Alvaro Herrera <alvherre@alvh.no-ip.org>

View thread
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, exclusion@gmail.com, dean.a.rasheed@gmail.com, andrewbille@gmail.com, peter@eisentraut.org, pgsql-hackers@lists.postgresql.org, Justin Pryzby <pryzby@telsasoft.com>
Date: 2024-05-14T09:58:11Z
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. Revert structural changes to not-null constraints

  2. Fix inconsistencies in error messages

  3. Disallow direct change of NO INHERIT of not-null constraints

  4. Disallow NO INHERIT not-null constraints on partitioned tables

  5. Better handle indirect constraint drops

  6. Don't try to assign smart names to constraints

  7. Fix restore of not-null constraints with inheritance

  8. ATTACH PARTITION: Don't match a PK with a UNIQUE constraint

  9. Fix propagating attnotnull in multiple inheritance

  10. Check stack depth in new recursive functions

  11. Move privilege check to the right place

  12. Update information_schema definition for not-null constraints

  13. Fix not-null constraint test

  14. Disallow changing NO INHERIT status of a not-null constraint

  15. Catalog not-null constraints

  16. parallel_schedule: add comment on event_trigger test dependency

  17. Revert "Catalog NOT NULL constraints" and fallout

  18. Adjust contrib/sepgsql regression test expected outputs.

  19. Fix table name clash in recently introduced test

  20. Catalog NOT NULL constraints

  21. Change the rules for inherited CHECK constraints to be essentially the same

On 2024-May-13, Robert Haas wrote:

> It seems to me that the practical thing to do about this problem is
> just decide not to solve it. I mean, it's currently the case that if
> you establish a PRIMARY KEY when you create a table, the columns of
> that key are marked NOT NULL and remain NOT NULL even if the primary
> key is later dropped. So, if that didn't change, we would be no less
> compliant with the SQL standard (or your reading of it) than we are
> now.
[...]
> So I don't really think it's a great idea to change this behavior, but
> even if it is, is it such a good idea that we want to sink the whole
> patch set repeatedly over it, as has already happened twice now? I
> feel that if we did what Tom suggested a year ago in
> https://www.postgresql.org/message-id/3801207.1681057430@sss.pgh.pa.us
> -- "I'm inclined to think that this idea of suppressing the implied
> NOT NULL from PRIMARY KEY is a nonstarter and we should just go ahead
> and make such a constraint" [...]

Hmm, I hadn't interpreted Tom's message the way you suggest, and you may
be right that it might be a good way forward.  I'll keep this in mind
for next time.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"No es bueno caminar con un hombre muerto"