> On Thu, Nov 21, 2024 at 1:01 PM Erki Eessaar <erki.eessaar@taltech.ee> > wrote: > > > SELECT pg_get_constraintdef(c.oid) > > FROM pg_catalog.pg_constraint c; > > > > If I execute the query in two different servers with PostgreSQL 17.1 and > > in different databases in these servers, then I get the answer > > > > ERROR: invalid constraint type "n"
> Looks like this is an omission in the catalog-not-null-constraints patch. > It happens when you've got a domain that has a not null constraint on it. > Easily reproducible with > > create domain test as int int not null; > SELECT pg_get_constraintdef(c.oid) FROM pg_catalog.pg_constraint c;
Ah, yeah. The overall catalog-not-null-constraints patch was reverted in 17 (and recently reintroduced in 18). But we kept not-null constraints for domains. However, the ruleutils.c code to support domain ones wasn't kept. So we need something based on the attached patch, which just copies what the code in 18 does for the domain case.
I wonder if there are other places that need to handle these constraint entries, though.
I can confirm that fixes it.
A quick grep for example shows that CONSTRAINT_TRIGGER is only used in that same place, so that should at least be the only case-statement that needs them all. But I really don't know enough about that code to comment on whether there are other likely places for it :)
