Constraint check is missing value check ARRAY

On Fri, 2026-09-11 at 19:09 +0000, PG Doc comments form wrote:

This page is missing the value check array.
https://www.postgresql.org/docs/current/ddl-constraints.html

Example:
CREATE TABLE demo
(
 id bigint NOT NULL DEFAULT nextval('seq_ttelephone_id'::regclass),
 usage character(1) NOT NULL  DEFAULT 'M',
 CONSTRAINT ck_ttelephone_usage_1 CHECK (usage = ANY
(ARRAY['M'::character(1),'H'::character(1),'W'::character(1),'F'::character(1)]))
NOT VALID
)
);

This is entirely missing from the documentation.

Key thing to point out is the type cast must match:
e.g. character(1) for type of character(1) etc

Which aspect of this requires more detailed documentation than already exists?
Can you be more descriptive?

Yours,
Laurenz Albe

Hi Laurenz,

As far as I can tell:
https://www.postgresql.org/docs/current/ddl-constraints.html
Has nothing on a check array constraint, or an oracle example for
previous "*CHECK
usage IN ('M', 'H', 'W', 'F')*"
I.e this is an enum of values:

*CHECK (usage =
ANY (ARRAY['M'::character(1),'H'::character(1),'W'::character(1),'F'::character(1)]))
NOT
VALID*

Please can it be added into the documentation, or a URL given by return
that contains it.
I have been unable to find any in recent documentation. I am pretty sure it
existed in old documentation, or I reverse engineered it from pgAdmin
software.
I would be very useful to have it documented properly.

That URL above includes all the other value constraints (against comparator
const, against comparator variable, unique and foreign key), but nothing
for a fixed limited set of equals values.

In the above example I provided it is needed as not all letters are valid.
Another example would be "displayed = Y, N"

Postgres is a little more finicky than oracle, but the feature exists, and
works nicely, just with awkward syntax.
All I am asking is the documentation to include it.

Many thanks

Eugene

On Sun, 13 Sept 2026 at 22:41, Laurenz Albe <laurenz.albe@cybertec.at>
wrote:

On Fri, 2026-09-11 at 19:09 +0000, PG Doc comments form wrote:

This page is missing the value check array.
https://www.postgresql.org/docs/current/ddl-constraints.html

Example:
CREATE TABLE demo
(
id bigint NOT NULL DEFAULT nextval('seq_ttelephone_id'::regclass),
usage character(1) NOT NULL DEFAULT 'M',
CONSTRAINT ck_ttelephone_usage_1 CHECK (usage = ANY

(ARRAY['M'::character(1),'H'::character(1),'W'::character(1),'F'::character(1)]))

NOT VALID
)
);

This is entirely missing from the documentation.

Key thing to point out is the type cast must match:
e.g. character(1) for type of character(1) etc

Which aspect of this requires more detailed documentation than already
exists?
Can you be more descriptive?

Yours,
Laurenz Albe

--

*Eugene Losowski-Gallagher*
*Mob: *07825160923

On Mon, 2026-09-14 at 07:45 +0100, Eugene Losowski-Gallagher wrote:

As far as I can tell:
https://www.postgresql.org/docs/current/ddl-constraints.html
Has nothing on a check array constraint, or an oracle example for previous "CHECK usage IN ('M', 'H', 'W', 'F')"
I.e this is an enum of values:

CHECK (usage = ANY (ARRAY['M'::character(1),'H'::character(1),'W'::character(1),'F'::character(1)])) NOT VALID

Please can it be added into the documentation, or a URL given by return that contains it.
I have been unable to find any in recent documentation. I am pretty sure it existed in old documentation, or I reverse engineered it from pgAdmin software.
I would be very useful to have it documented properly.

That URL above includes all the other value constraints (against comparator const, against comparator variable, unique and foreign key), but nothing for a fixed limited set of equals values.

In the above example I provided it is needed as not all letters are valid.
Another example would be "displayed = Y, N"

Postgres is a little more finicky than oracle, but the feature exists, and works nicely, just with awkward syntax.
All I am asking is the documentation to include it.

There is no special "check array constraint", so there is no point in documenting it.

The following syntax works fine with PostgreSQL:

CHECK (usage IN ('M', 'H', 'W', 'F'))

True, your alternative spelling works just as well, but there is nothing
mysterious about it:

- <operator> ANY is documented in [1]https://www.postgresql.org/docs/current/functions-subquery.html#FUNCTIONS-SUBQUERY-ANY-SOME

- the ARRAY[] constructor syntax is documented in [2]https://www.postgresql.org/docs/current/arrays.html#ARRAYS-INPUT

- the proprietary type cast syntax using :: is documented in [3]https://www.postgresql.org/docs/current/sql-expressions.html#SQL-SYNTAX-TYPE-CASTS

There is no special check constraint syntax in play that would need
additional documentation.

Yours,
Laurenz Albe

[1]: https://www.postgresql.org/docs/current/functions-subquery.html#FUNCTIONS-SUBQUERY-ANY-SOME
[2]: https://www.postgresql.org/docs/current/arrays.html#ARRAYS-INPUT
[3]: https://www.postgresql.org/docs/current/sql-expressions.html#SQL-SYNTAX-TYPE-CASTS

On Monday, September 14, 2026, Laurenz Albe <laurenz.albe@cybertec.at>
wrote:

That URL above includes all the other value constraints (against

comparator const, against comparator variable, unique and foreign key), but
nothing for a fixed limited set of equals values.

In the above example I provided it is needed as not all letters are

valid.

Another example would be "displayed = Y, N"

Postgres is a little more finicky than oracle, but the feature exists,

and works nicely, just with awkward syntax.

All I am asking is the documentation to include it.

There is no special "check array constraint", so there is no point in
documenting it.

I concur. That section assumes one knows how to write a “boolean
(truth-value) expression” or can go find that out by reading the relevant
sections on writing expressions - which are used everywhere in the system.
Places that simply allow for expressions to be present need not cover the
topic in detail.

The documentation isn’t a book of examples or idea generators. Examples
are used to make a point as to the correct usage of a feature but make no
attempt to be a comprehensive idea generator for how a feature could be
used.

It also doesn’t really try to deal with the fact that some readers may come
along with preconceptions that mislead them. Using an array there is also
not particularly idiomatic in any case. The status quo seems warranted -
the comparator classification quoted above is an interesting one but not
something this documentation has framed up; both of those are simply
boolean expressions which is how the docs framed it.

David J.