Re: Function pg_get_constraintdef
От | Magnus Hagander |
---|---|
Тема | Re: Function pg_get_constraintdef |
Дата | |
Msg-id | CABUevExn=jj1Jd6By8RpAxXJ91kp1UHQzB=WpQtPf9hhaY45Qw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Function pg_get_constraintdef (Magnus Hagander <magnus@hagander.net>) |
Ответы |
Re: Function pg_get_constraintdef
|
Список | pgsql-bugs |
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 :)
В списке pgsql-bugs по дате отправления: