On Jun 17, 2024, at 6:44 PM, Chapman Flack <jcflack@acm.org> wrote:
> 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.
Naw, executePredicate does it for all of them, as for the left operand here[1].
> 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.
Yes, and they’re handled consistently, at least.
> 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’m okay without the errors, as long as the behaviors are consistent. I mean it might be cool to have a way to get
them,but the consistency I thought I saw was the bit that seemed like a bug.
> 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.
Right, same for using jsonb_path_match().
> 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.
EXTREAMLY FALSE! 😂
> 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.
Thaat seems like it’d be confusing TBH.
> 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).
The only options I can think of are a GUC to turn on SUPER STRICT mode or something (yuck, action at a distance) or
introducenew functions with the new behavior. I advocate for neither (at this point).
Best,
David
[1]: https://github.com/postgres/postgres/blob/82ed67a/src/backend/utils/adt/jsonpath_exec.c#L2058-L2059