Re: Function pg_get_constraintdef

On Thu, Nov 21, 2024 at 1:30 PM Alvaro Herrera <alvherre@alvh.no-ip.org>
wrote:

> On 2024-Nov-21, Magnus Hagander wrote:
>
> > 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 :)

-- 
 Magnus Hagander
 Me: https://www.hagander.net/ <http://www.hagander.net/>
 Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>