This error occurs when a JSON path expression in strict mode fails to match the expected structure of your JSON data. Using lax mode or handling errors with ON EMPTY/ON ERROR clauses resolves the issue.
The "No SQL/JSON item" error in PostgreSQL occurs when you use a strict SQL/JSON path expression that encounters a structural error—such as accessing a non-existent object field or array element. In strict mode, PostgreSQL raises an error instead of silently returning no results. This is a safety feature to catch logic errors in your JSON queries, but it requires proper error handling or schema matching. In lax mode (the default), structural errors are suppressed and return no match, which is often less obvious to debug.
Lax mode (the default) automatically adapts the path expression to match your data and suppresses structural errors. If you are using explicit strict mode, remove it:
-- BEFORE (strict mode): raises error if field missing
SELECT jsonb_path_query(data, 'strict $.email') FROM users;
-- AFTER (lax mode): returns null if field missing
SELECT jsonb_path_query(data, '$.email') FROM users;Lax mode handles missing fields, array index mismatches, and type issues gracefully by returning empty results instead of errors.
If you are using PostgreSQL 17 or later, use ON EMPTY and ON ERROR clauses to explicitly handle cases where the path returns no results or encounters an error:
-- Return a default value if path returns empty
SELECT jsonb_path_query_first(
data,
'$.email'
RETURNING text
NULL ON EMPTY
) FROM users;
-- Specify behavior for both empty and error conditions
SELECT jsonb_path_query_first(
data,
'$.email'
RETURNING text
DEFAULT 'no-email' ON EMPTY
DEFAULT 'error' ON ERROR
) FROM users;This approach gives you fine-grained control over error handling.
For functions like jsonb_path_exists(), jsonb_path_match(), and jsonb_path_query(), use the optional silent argument to suppress errors:
-- Without silent parameter: may raise errors
SELECT jsonb_path_query(data, 'strict $.address.zipcode') FROM users;
-- With silent = true: suppresses errors and returns null
SELECT jsonb_path_query(data, 'strict $.address.zipcode', silent => true) FROM users;
-- For jsonb_path_exists with silent mode
SELECT * FROM users WHERE jsonb_path_exists(data, '$.email', silent => true);The silent parameter suppresses missing field, type mismatch, and datetime/numeric errors without changing the path expression mode.
Inspect the actual JSON data to ensure your path expression is correct. Use jsonb_pretty() to visualize the structure:
-- View the JSON structure
SELECT jsonb_pretty(data) FROM users LIMIT 1;
-- Test the path expression
SELECT jsonb_path_query_array(data, '$') FROM users LIMIT 1;
-- Check if a specific path exists before querying it
SELECT * FROM users WHERE jsonb_path_exists(data, '$.email');Make sure your path expression matches the actual nesting levels and field names in your JSON documents.
The @? (path exists) and @@ (path matches) operators automatically suppress structural errors:
-- Check if path exists safely (errors suppressed)
SELECT * FROM users WHERE data @? '$.email';
-- Use @@ for path matching with filter
SELECT * FROM users WHERE data @@ '$.age > 18';
-- Combine with -> or ->> for safe extraction
SELECT data -> 'email' AS email FROM users WHERE data @? '$.email';These operators are safe to use in strict mode contexts and avoid "No SQL/JSON item" errors.
PostgreSQL's SQL/JSON path language follows the ECMA-404 standard but with two distinct modes. Lax mode is designed for schema-flexible queries where JSON documents may have varying structures. Strict mode is for catching logic errors when you expect an exact schema. If you are migrating from other databases with JSON support, note that PostgreSQL's strict mode error handling differs from MySQL (which returns NULL) and MongoDB (which uses optional path syntax). The ON EMPTY and ON ERROR clauses in PostgreSQL 17+ provide more control than earlier versions, making them the recommended approach for new code. For performance-critical queries with large JSON documents, use jsonb_path_exists() to test existence before extracting values, avoiding unnecessary path evaluation.
ERROR: syntax error at end of input
Syntax error at end of input in PostgreSQL
Bind message supplies N parameters but prepared statement requires M
Bind message supplies N parameters but prepared statement requires M in PostgreSQL
Multidimensional arrays must have sub-arrays with matching dimensions
Multidimensional arrays must have sub-arrays with matching dimensions
ERROR: value too long for type character varying
Value too long for type character varying
insufficient columns in unique constraint for partition key
How to fix "insufficient columns in unique constraint for partition key" in PostgreSQL