On Jun 17, 2024, at 6:44 PM, Chapman Flack <jcfl...@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 introduce new 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
