On Tue, 20 Sept 2022 at 06:56, Alvaro Herrera <alvhe...@alvh.no-ip.org> wrote:
The NULL checks would still be mostly done by the attnotnull checks > internally, so there shouldn't be too much of a difference. > > .. though I'm now wondering if there's additional overhead from checking > the constraint twice on each row: first the attnotnull bit, then the > CHECK itself. Hmm. That's probably quite bad. > Another reason to treat NOT NULL-implementing constraints differently. My thinking is that pg_constraint entries for NOT NULL columns are mostly an implementation detail. I've certainly never cared whether I had an actual constraint corresponding to my NOT NULL columns. So I think marking them as such, or a different contype, and excluding them from \d+ display, probably makes sense. Just need to deal with the issue of trying to create a constraint and having its name conflict with a NOT NULL constraint. Could it work to reserve [field name]_notnull for NOT NULL-implementing constraints? I'd be worried about what happens with field renames; renaming the constraint automatically seems a bit weird, but maybe…
