From: Chapman Flack <jcflack@acm.org>
To: David E. Wheeler <david@justatheory.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: jsonpath: Missing regex_like && starts with Errors?
Date: Mon, 17 Jun 2024 18:44:41 -0400
Message-ID: <6670BC59.1010204@acm.org> (raw)
In-Reply-To: <9BAFB50F-267E-4078-9558-36155E93A723@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>
On 06/17/24 18:14, David E. Wheeler wrote:
> So I think that’s the key: There’s not a difference between 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 saying
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 errors,
but not when inside a <JSON filter expression>, and that would also satisfy
the standard, but it would also give us the errors you would like from our
nonstandard "predicate check expressions". And then you could easily use
silent => 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, and
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: jcflack@acm.org, david@justatheory.com, pgsql-hackers@lists.postgresql.org
Subject: Re: jsonpath: Missing regex_like && starts with Errors?
In-Reply-To: <6670BC59.1010204@acm.org>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox