Re: cataloguing NOT NULL constraints
| От | Isaac Morland |
|---|---|
| Тема | Re: cataloguing NOT NULL constraints |
| Дата | |
| Msg-id | CAMsGm5dSb-ovQb8zk=enfbG+zy16iHZFSHNyXTB2gYtjPsy7fg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: cataloguing NOT NULL constraints (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
| Ответы |
Re: cataloguing NOT NULL constraints
|
| Список | pgsql-hackers |
On Tue, 20 Sept 2022 at 06:56, Alvaro Herrera <alvherre@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…
В списке pgsql-hackers по дате отправления: