On Jun 14, 2024, at 22:29, Chapman Flack <jcflack@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
standardsince Postgres 12[1]. I found their behavior quite confusing for a while, and spent some time figuring it out
andsubmitting 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
`startswith` 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
