Re: Catalog domain not-null constraints

On Tue, Mar 26, 2024 at 2:28 AM Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> wrote:
>
> On Fri, 22 Mar 2024 at 08:28, jian he <jian(dot)universality(at)gmail(dot)com> wrote:
> >
> > On Thu, Mar 21, 2024 at 7:23 PM Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
> > >
> > > Hmm. CREATE DOMAIN uses column constraint syntax, but ALTER DOMAIN uses
> > > table constraint syntax. Attached is a patch to try to sort this out.
> >
> > also you should also change src/backend/utils/adt/ruleutils.c?
> >
> > src6=# \dD
> > List of domains
> > Schema | Name | Type | Collation | Nullable | Default |
> > Check
> > --------+-------------+---------+-----------+----------+---------+----------------------------------
> > public | domain_test | integer | | not null | |
> > CHECK (VALUE > 0) NOT NULL VALUE
> > (1 row)
> >
> > probably change to CHECK (VALUE IS NOT NULL)
>
> I'd say it should just output "NOT NULL", since that's the input
> syntax that created the constraint. But then again, why display NOT
> NULL constraints in that column at all, when there's a separate
> "Nullable" column?
>
create table sss(a int not null);
SELECT pg_get_constraintdef(oid) FROM pg_constraint WHERE conname =
'sss_a_not_null';
returns
" NOT NULL a"

I think just outputting "NOT NULL" is ok for the domain, given the
table constraint is "NOT NULL" + table column, per above example.
yech, we already have a "Nullable" column, so we don't need to display
NOT NULL constraints.