Re: cataloguing NOT NULL constraints - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: cataloguing NOT NULL constraints
Date
Msg-id 20230712171059.4cqn7f7x3f4tdff3@alvherre.pgsql
Whole thread Raw
In response to Re: cataloguing NOT NULL constraints  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: cataloguing NOT NULL constraints
List pgsql-hackers
v13, because a conflict was just committed to alter_table.sql.

Here I also call out the relcache.c change by making it a separate
commit.  I'm likely to commit it that way, too.  To recap: the change is
to have a partitioned table's index list include the primary key, even
when said primary key is marked invalid.  This turns out to be necessary
for the currently proposed pg_dump strategy to work; if this is not in
place, attaching the per-partition PK indexes to the parent index fails
because it sees that the columns are not marked NOT NULL.

I don't see any obvious problem with this change; but if someone does
and this turns out to be unacceptable, then the pg_dump stuff would need
some surgery.

There are no other changes from v12.  One thing I should probably get
to, is fixing the constraint name comparison code in pg_dump.  Right now
it's a bit dumb and will get in silly trouble with overlength
table/column names (nothing that would actually break, just that it will
emit constraint names when there's no need to.)

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/
Essentially, you're proposing Kevlar shoes as a solution for the problem
that you want to walk around carrying a loaded gun aimed at your foot.
(Tom Lane)

Attachment

pgsql-hackers by date:

Previous
From: "Tristan Partin"
Date:
Subject: Re: Meson build updates
Next
From: Gurjeet Singh
Date:
Subject: Re: Better help output for pgbench -I init_steps