| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Isaac Morland <isaac(dot)morland(at)gmail(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: cataloguing NOT NULL constraints |
| Date: | 2022-09-19 14:08:52 |
| Message-ID: | 335175.1663596532@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Isaac Morland <isaac(dot)morland(at)gmail(dot)com> writes:
> I thought I saw some discussion about the SQL standard saying that there is
> a difference between putting NOT NULL in a column definition, and CHECK
> (column_name NOT NULL). So if we're going to take this seriously, I think
> that means there needs to be a field in pg_constraint which identifies
> whether a constraint is a "real" one created explicitly as a constraint, or
> if it is just one created because a field is marked NOT NULL.
If we're going to go that way, I think that we should take the further
step of making not-null constraints be their own contype rather than
an artificially generated CHECK. The bloat in pg_constraint from CHECK
expressions made this way seems like an additional reason not to like
doing it like that.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Matthias van de Meent | 2022-09-19 14:10:17 | Re: cataloguing NOT NULL constraints |
| Previous Message | Tom Lane | 2022-09-19 14:00:05 | Re: Tree-walker callbacks vs -Wdeprecated-non-prototype |