Re: cataloguing NOT NULL constraints

Andres Freund <andres@anarazel.de>

From: Andres Freund <andres@anarazel.de>

To: Tom Lane <tgl@sss.pgh.pa.us>

Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>, Justin Pryzby <pryzby@telsasoft.com>, Peter Eisentraut <peter.eisentraut@enterprisedb.com>, pgsql-hackers@lists.postgresql.org

Date: 2023-04-08T00:19:42Z

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 →

Revert structural changes to not-null constraints
- 6f8bb7c1e961 17.0 landed
Fix inconsistencies in error messages
- 21ac38f498b3 17.0 landed
Disallow direct change of NO INHERIT of not-null constraints
- d45597f72fe5 17.0 landed
Disallow NO INHERIT not-null constraints on partitioned tables
- 13daa33fa5a6 17.0 landed
Better handle indirect constraint drops
- 0cd711271d42 17.0 cited
Don't try to assign smart names to constraints
- d72d32f52d26 17.0 cited
Fix restore of not-null constraints with inheritance
- d9f686a72ee9 17.0 landed
ATTACH PARTITION: Don't match a PK with a UNIQUE constraint
- cee8db3f680b 17.0 landed
Fix propagating attnotnull in multiple inheritance
- c3709100be73 17.0 landed
Check stack depth in new recursive functions
- b0f7dd915bca 17.0 landed
Move privilege check to the right place
- ac22a9545ca9 17.0 cited
Update information_schema definition for not-null constraints
- 3af721794272 17.0 landed
Fix not-null constraint test
- d0ec2ddbe088 17.0 landed
Disallow changing NO INHERIT status of a not-null constraint
- 9b581c534186 17.0 cited
Catalog not-null constraints
- b0e96f311985 17.0 cited
parallel_schedule: add comment on event_trigger test dependency
- c8e43c22be27 17.0 landed
Revert "Catalog NOT NULL constraints" and fallout
- 9ce04b50e120 16.0 landed
Adjust contrib/sepgsql regression test expected outputs.
- 76c111a7f166 16.0 landed
Fix table name clash in recently introduced test
- 728015a47016 16.0 landed
Catalog NOT NULL constraints
- e056c557aef4 16.0 landed
Change the rules for inherited CHECK constraints to be essentially the same
- cd902b331dc4 8.4.0 cited

Hi,

On 2023-04-07 18:26:28 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2023-04-07 17:46:33 -0400, Tom Lane wrote:
> >> After quickly eyeing the diffs, I'm just going to take the new output
> >> as good.  I'm not surprised that there are additional output messages
> >> given the additional catalog entries this made.  I *am* a bit surprised
> >> that some messages seem to have disappeared --- are there places where
> >> this resulted in fewer catalog accesses than before?  Nonetheless,
> >> there's no good reason to assume this test is exposing any bugs.
> 
> > I wonder if the issue is that the new paths miss a hook invocation.
> 
> Perhaps.  I'm content to silence the buildfarm for today; we can
> investigate more closely later.

Makes sense.

I think
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=drongo&dt=2023-04-07%2021%3A16%3A04
might point out a problem with the pg_dump or pg_upgrade backward compat
paths:

--- C:\\prog\\bf/root/upgrade.drongo/HEAD/origin-REL9_5_STABLE.sql.fixed	2023-04-07 23:51:27.641328600 +0000
+++ C:\\prog\\bf/root/upgrade.drongo/HEAD/converted-REL9_5_STABLE-to-HEAD.sql.fixed	2023-04-07 23:51:27.672571900 +0000
@@ -416,9 +416,9 @@
 -- Name: entry; Type: TABLE; Schema: public; Owner: buildfarm
 --
 CREATE TABLE public.entry (
-    accession text,
-    eid integer,
-    txid smallint
+    accession text NOT NULL,
+    eid integer NOT NULL,
+    txid smallint NOT NULL
 );
 ALTER TABLE public.entry OWNER TO buildfarm;
 --

Looks like we're making up NOT NULL constraints when migrating from 9.5, for
some reason?

Greetings,

Andres Freund