On Jun 14, 2024, at 22:29, Chapman Flack <jcfl...@acm.org> wrote: > So I should go look at our code to see what grammar we've implemented, > exactly. It is beginning to seem as if we have simply added > <JSON path predicate> as another choice for an expression, not restricted > to only appearing in a filter. If so, and we add documentation about how > we diverge from the standard, that's probably the way to say it.
Yes, if I understand correctly, these are predicate check expressions, supported and documented as an extension to the standard since Postgres 12[1]. I found their behavior quite confusing for a while, and spent some time figuring it out and submitting a doc patch (committed in 7014c9a[2]) to hopefully clarify things in Postgres 17. > So that's where the errors went. Ah, great, that explains the error suppression in filters. Thank you. I still think the supression of `like_regex` and `starts with` errors in predicate path queries is odd, though. > The question of what should happen to the errors when a > <JSON path predicate> appears outside of a <JSON filter expression> > of course isn't answered in the standard, because that's not supposed > to be possible. So if we're allowing predicates to appear on their own > as expressions, it's also up to us to say what should happen with errors > when they do. Right, and I think there’s an inconsistency right now. Best, David [1]: https://www.postgresql.org/docs/devel/functions-json.html#FUNCTIONS-SQLJSON-CHECK-EXPRESSIONS [2]: https://github.com/postgres/postgres/commit/7014c9a
