Re: Catalog domain not-null constraints

jian he <jian.universality@gmail.com>

From: jian he <jian.universality@gmail.com>
To: Peter Eisentraut <peter@eisentraut.org>
Cc: Dean Rasheed <dean.a.rasheed@gmail.com>, Aleksander Alekseev <aleksander@timescale.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, Alvaro Herrera <alvherre@alvh.no-ip.org>, vignesh C <vignesh21@gmail.com>
Date: 2024-04-09T08:44:18Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Fix ALTER DOMAIN NOT NULL syntax

  2. Catalog domain not-null constraints

  3. Add tests for domain-related information schema views

Attachments

On Mon, Apr 8, 2024 at 5:53 PM Peter Eisentraut <peter@eisentraut.org> wrote:
>
> On 21.03.24 12:23, Peter Eisentraut wrote:
> >> All the examples in the tests append "value" to this, presumably by
> >> analogy with CHECK constraints, but it looks as though anything works,
> >> and is simply ignored:
> >>
> >> ALTER DOMAIN d ADD CONSTRAINT nn NOT NULL xxx; -- works
> >>
> >> That doesn't seem particularly satisfactory. I think it should not
> >> require (and reject) a column name after "NOT NULL".
> >
> > Hmm.  CREATE DOMAIN uses column constraint syntax, but ALTER DOMAIN uses
> > table constraint syntax.  As long as you are only dealing with CHECK
> > constraints, there is no difference, but it shows up when using NOT NULL
> > constraint syntax.  I agree that this is unsatisfactory.  Attached is a
> > patch to try to sort this out.
>
> After studying this a bit more, I think moving forward in this direction
> is the best way.  Attached is a new patch version, mainly with a more
> elaborate commit message.  This patch makes the not-null constraint
> syntax consistent between CREATE DOMAIN and ALTER DOMAIN, and also makes
> the respective documentation correct.
>
> (Note that, as I show in the commit message, commit e5da0fe3c22 had in
> passing fixed a couple of bugs in CREATE and ALTER DOMAIN, so just
> reverting that commit wouldn't be a complete solution.)


in ruleutils.c
/* conkey is null for domain not-null constraints */
appendStringInfoString(&buf, "NOT NULL VALUE");

should be

/* conkey is null for domain not-null constraints */
appendStringInfoString(&buf, "NOT NULL ");
?


currently
src6=# \dD connotnull
/******** QUERY *********/
SELECT n.nspname as "Schema",
       t.typname as "Name",
       pg_catalog.format_type(t.typbasetype, t.typtypmod) as "Type",
       (SELECT c.collname FROM pg_catalog.pg_collation c, pg_catalog.pg_type bt
        WHERE c.oid = t.typcollation AND bt.oid = t.typbasetype AND
t.typcollation <> bt.typcollation) as "Collation",
       CASE WHEN t.typnotnull THEN 'not null' END as "Nullable",
       t.typdefault as "Default",
       pg_catalog.array_to_string(ARRAY(
         SELECT pg_catalog.pg_get_constraintdef(r.oid, true) FROM
pg_catalog.pg_constraint r WHERE t.oid = r.contypid
       ), ' ') as "Check"
FROM pg_catalog.pg_type t
     LEFT JOIN pg_catalog.pg_namespace n ON n.oid = t.typnamespace
WHERE t.typtype = 'd'
  AND t.typname OPERATOR(pg_catalog.~) '^(connotnull)$' COLLATE
pg_catalog.default
  AND pg_catalog.pg_type_is_visible(t.oid)
ORDER BY 1, 2;
/************************/

---
Since the last column is already named as "Check", maybe we need to
change the query to
       pg_catalog.array_to_string(ARRAY(
         SELECT pg_catalog.pg_get_constraintdef(r.oid, true) FROM
pg_catalog.pg_constraint r WHERE t.oid = r.contypid
         and r.contype = 'c'
       ), ' ') as "Check"

That means domain can be associated with check constraint and not-null
constraint.



the url link destination is fine, but the url rendered name is "per
the section called “Notes”" which seems strange,
please see attached.