is_jsonb_valid

is_jsonb_valid : Native JSONB validation against JSON Schema drafts 4 and 7

Overview

Packages

Source

pig build pkg is_jsonb_valid;		# build rpm/deb

Install

Make sure PGDG and PIGSTY repo available:

pig repo add pgsql -u   # add both repo and update cache

Install this extension with pig:

pig install is_jsonb_valid;		# install via package name, for the active PG version

pig install is_jsonb_valid -v 18;   # install for PG 18
pig install is_jsonb_valid -v 17;   # install for PG 17
pig install is_jsonb_valid -v 16;   # install for PG 16
pig install is_jsonb_valid -v 15;   # install for PG 15
pig install is_jsonb_valid -v 14;   # install for PG 14

Create this extension with:

CREATE EXTENSION is_jsonb_valid;

Usage

Sources:

• Official README at the catalog source revision
• Extension control file at the catalog source revision
• Version 0.1.4 extension SQL
• PGXN distribution page

is_jsonb_valid provides native boolean validation of JSONB values against JSON Schema Draft 4 or Draft 7. It is suitable for checks and predicates that need only pass/fail output; it does not return a path or diagnostic explaining a failed keyword.

Core Workflow

Choose the function that matches the schema draft and pass the schema first, followed by the value being validated.

CREATE EXTENSION is_jsonb_valid;

SELECT is_jsonb_valid(
    '{"type":"object","required":["id"],"properties":{"id":{"type":"integer"}}}'::jsonb,
    '{"id":42}'::jsonb
);

SELECT is_jsonb_valid_draft_v7(
    '{"if":{"exclusiveMaximum":0},"else":{"multipleOf":2}}'::jsonb,
    '4'::jsonb
);

The two functions are strict and immutable in version 0.1.4. This makes them usable in constraints and indexes when the schema is stable.

CREATE TABLE events (
    payload jsonb NOT NULL,
    CONSTRAINT events_payload_valid CHECK (
        is_jsonb_valid(
            '{"type":"object","required":["id"]}'::jsonb,
            payload
        )
    )
);

Draft Boundary and Limitations

The base validator follows Draft 4; the explicitly named alternative follows Draft 7. Select deliberately, because keyword meaning differs between drafts and the extension does not infer the draft from a schema declaration.

At the pinned revision, remote references are unsupported. Local references are limited to definitions reachable from the schema root, and identifier changes along a reference chain are not resolved. Format validation is also unsupported. These gaps mean a true result is only a claim about the implemented subset, not every behavior in the complete JSON Schema specifications.

No preload or restart is declared. Keep schema literals and application expectations under version control, and add representative valid and invalid cases whenever a constraint depends on this extension.