Horton

Re: Catalog domain not-null constraints

Peter Eisentraut <peter@eisentraut.org>

View thread
From: Peter Eisentraut <peter@eisentraut.org>
To: vignesh C <vignesh21@gmail.com>
Cc: Aleksander Alekseev <aleksander@timescale.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2024-01-18T06:53:57Z
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

On 17.01.24 13:15, vignesh C wrote:
> One of the test has failed in CFBot at [1] with:
> diff -U3 /tmp/cirrus-ci-build/src/test/regress/expected/domain.out
> /tmp/cirrus-ci-build/src/test/regress/results/domain.out
> --- /tmp/cirrus-ci-build/src/test/regress/expected/domain.out
> 2024-01-14 15:40:01.793434601 +0000
> +++ /tmp/cirrus-ci-build/src/test/regress/results/domain.out
> 2024-01-14 15:42:23.013332625 +0000
> @@ -1271,11 +1271,4 @@
>               FROM information_schema.domain_constraints
>               WHERE domain_name IN ('con', 'dom', 'pos_int', 'things'))
>     ORDER BY constraint_name;
> - constraint_catalog | constraint_schema | constraint_name  |   check_clause
> ---------------------+-------------------+------------------+-------------------
> - regression         | public            | con_check        | (VALUE > 0)
> - regression         | public            | meow             | (VALUE < 11)
> - regression         | public            | pos_int_check    | (VALUE > 0)
> - regression         | public            | pos_int_not_null | VALUE IS NOT NULL
> -(4 rows)
> -
> +ERROR:  could not open relation with OID 36379
> 
> [1] - https://cirrus-ci.com/task/4536440638406656
> [2] - https://api.cirrus-ci.com/v1/artifact/task/4536440638406656/log/src/test/regress/regression.diffs

Interesting.  I couldn't reproduce this locally, even across different 
operating systems.  The cfbot failures appear to be sporadic, but also 
happening across multiple systems, so it's clearly not just a local 
environment failure.  Can anyone else perhaps reproduce this locally?