On Jun 16, 2024, at 11:52, David E. Wheeler <[email protected]> wrote:
> I think that’s how it should be; I prefer that it raises errors by default
> but you can silence them:
>
> david=# select jsonb_path_query(target => '{"x": "hi"}', path =>
> '$.integer()', silent => false);
> ERROR: jsonpath item method .integer() can only be applied to a string or
> numeric value
>
> david=# select jsonb_path_query(target => '{"x": "hi"}', path =>
> '$.integer()', silent => true);
> jsonb_path_query
> ------------------
> (0 rows)
>
> I suggest that the same behavior be adopted for `like_regex` and `starts
> with`.
Okay, I think I’ve figured this out, and the key is that I am, once again,
comparing predicate path queries to SQL standard queries. If I update the first
example to use a comparison I no longer get an error:
david=# select jsonb_path_query('{"x": "hi"}', '$.integer() == 1');
jsonb_path_query
------------------
null
So I think that’s the key: There’s not a difference between the behavior of
`like_regex` and `starts with` vs other predicate expressions.
This dichotomy continues to annoy. I would very much like some way to have
jsonb_path_query() raise an error (or even a warning!) if passed a predate
expression, and for jsonb_path_match() to raise an error or warning if its path
is not a predicate expression. Because I keep confusing TF out of myself.
Best,
David
