Re: information_schema and not-null constraints

From: Vik Fearing <vik(at)postgresfriends(dot)org>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter(at)eisentraut(dot)org>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
Subject: Re: information_schema and not-null constraints
Date: 2023-09-05 21:50:04
Message-ID: d5a08654-33ea-0a12-8f95-e0029f65c75e@postgresfriends.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 9/5/23 19:15, Alvaro Herrera wrote:
> On 2023-Sep-05, Alvaro Herrera wrote:
>
> Looking now at what to do for CHECK_CONSTRAINTS with domain constraints,
> I admit I'm completely confused about what this view is supposed to
> show. Currently, we show the constraint name and a definition like
> "CHECK (column IS NOT NULL)". But since the table name is not given, it
> is not possible to know to what table the column name refers to. For
> domains, we could show "CHECK (VALUE IS NOT NULL)" but again with no
> indication of what domain it applies to, or anything at all that would
> make this useful in any way whatsoever.

Constraint names are supposed to be unique per schema[1] so the view
contains the minimum required information to identify the constraint.

> So this whole thing seems pretty futile and I'm disinclined to waste
> much time on it.

Until PostgreSQL either
A) obeys the spec on this uniqueness, or
B) decides to deviate from the information_schema spec;
this view will be completely useless for actually getting any useful
information.

I would like to see us do A because it is the right thing to do. Our
autogenerated names obey this rule, but who knows how many duplicate
names per schema are out there in the wild from people specifying their
own names.

I don't know what the project would think about doing B.

[1] SQL:2023-2 11.4 <table constraint definition> Syntax Rule 4
--
Vik Fearing

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David G. Johnston 2023-09-05 22:14:15 Re: information_schema and not-null constraints
Previous Message Nathan Bossart 2023-09-05 21:49:55 Re: Add 'worker_type' to pg_stat_subscription