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.1681057...@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"
