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>
 <666DBFEC.70201@acm.org>
 <F789151A-85EF-4D72-81CB-49E5472B3A78@justatheory.com>
 <9BAFB50F-267E-4078-9558-36155E93A723@justatheory.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
From: Chapman Flack <jcflack@acm.org>
Message-ID: <6670BC59.1010204@acm.org>
Date: Mon, 17 Jun 2024 18:44:41 -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: <9BAFB50F-267E-4078-9558-36155E93A723@justatheory.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/6670BC59.1010204%40acm.org>
Precedence: bulk

On 06/17/24 18:14, David E. Wheeler wrote:
> So I think that=E2=80=99s the key: There=E2=80=99s not a difference bet=
ween the behavior of
> `like_regex` and `starts with` vs other predicate expressions.

The current implementation seems to have made each of our
<JSON path predicate>s responsible for swallowing its own errors, which
is one perfectly cromulent way to satisfy the SQL standard behavior sayin=
g
all errors within a <JSON filter expression> should be swallowed.

The standard says nothing on how they should behave outside of a
<JSON filter expression>, because as far as the standard's concerned,
they can't appear there.

Ours currently behave the same way, and swallow their errors.

It would have been possible to write them in such a way as to raise error=
s,
but not when inside a <JSON filter expression>, and that would also satis=
fy
the standard, but it would also give us the errors you would like from ou=
r
nonstandard "predicate check expressions". And then you could easily use
silent =3D> true if you wanted them silent.

I'd be leery of changing that, though, as we've already documented that
a "predicate check expression" returns true, false, or unknown, so having
it throw by default seems like a change of documented behavior.

The current situation can't make much use of 'silent', since it's already
false by default; you can't make it any falser to make predicate-check
errors show up.

Would it be a thinkable thought to change the 'silent' default to null?
That could have the same effect as false for SQL standard expressions, an=
d
the same effect seen now for "predicate check expressions", and you could
pass it explicitly false if you wanted errors from the predicate checks.

If that's no good, I don't see an obvious solution other than adding
another nonstandard construct to what's nonstandard already, and allowing
something like nonsilent(predicate check expression).

Regards,
-Chap