Subject: Re: jsonpath: Missing regex_like && starts with Errors?
To: "David E. Wheeler" <david@justatheory.com>
References: <9272D3A9-8805-4DE1-A95F-84EB210EC121@justatheory.com>
 <666CFC8E.1000108@acm.org>
 <DE3701E1-E45E-489B-AFE8-68E1379EEAD3@justatheory.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
From: Chapman Flack <jcflack@acm.org>
Message-ID: <666DBFEC.70201@acm.org>
Date: Sat, 15 Jun 2024 12:23:08 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: <DE3701E1-E45E-489B-AFE8-68E1379EEAD3@justatheory.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/666DBFEC.70201%40acm.org>
Precedence: bulk

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#FUNCTION=
S-SQLJSON-CHECK-EXPRESSIONS

I see. Yes, that documentation now says "predicate check expressions retu=
rn
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, =E2=80=9Cunknown=E2=80=9D=
, 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