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
