On 06/15/24 10:47, David E. Wheeler wrote: > these are predicate check expressions, supported and documented > as an extension to the standard since Postgres 12[1]. > ... > [1]: > https://www.postgresql.org/docs/devel/functions-json.html#FUNCTIONS-SQLJSON-CHECK-EXPRESSIONS
I see. Yes, that documentation now says "predicate check expressions return the single three-valued result of the predicate: true, false, or unknown". (Aside: are all readers of the docs assumed to have learned the habit of calling SQL null "unknown" when speaking of a boolean? They can flip back to 8.6 Boolean Type and see 'a third state, “unknown”, which is represented by the SQL null value'. But would it save them some page flipping to add " (represented by SQL null)" to the sentence here?) As Unknown is typically what the predicates return within a filter (where errors get trapped) when an error has occurred, the existing docs seem to suggest they behave the same way in a "predicate check expression", so a change to that behavior now would be a change to what we've documented. OTOH, getting Unknown because some error occurred is strictly less information than seeing the error, so perhaps you would want a way to request non-error-trapping behavior for a "predicate check expression". Can't really overload jsonb_path_query's 'silent' parameter for that, because it is already false by default. If predicate check expressions were nonsilent by default, the existing 'silent' parameter would be a perfect way to silence them. No appetite to add yet another optional boolean parameter to jsonb_path_query for the sole purpose of controlling the silence of our nonstandard syntax extension .... Maybe just see the nonstandard syntax extension and raise it another one: expr_or_predicate : expr | predicate | "nonsilent" '(' predicate ')' ; or something like that. Regards, -Chap