Re: jsonpath: Missing regex_like && starts with Errors?
От | David E. Wheeler |
---|---|
Тема | Re: jsonpath: Missing regex_like && starts with Errors? |
Дата | |
Msg-id | DE3701E1-E45E-489B-AFE8-68E1379EEAD3@justatheory.com обсуждение исходный текст |
Ответ на | Re: jsonpath: Missing regex_like && starts with Errors? (Chapman Flack <jcflack@acm.org>) |
Ответы |
Re: jsonpath: Missing regex_like && starts with Errors?
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: