From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | "David E(dot) Wheeler" <david(at)justatheory(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Patch bug: Fix jsonpath .* on Arrays |
Date: | 2024-06-04 16:28:18 |
Message-ID: | CAKFQuwb=tJMm0NEn3NDVtzfaoNs73rcf3gbss7E5J9Lvns=y2w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tuesday, June 4, 2024, David E. Wheeler <david(at)justatheory(dot)com> wrote:
> Hackers,
>
> The behavior of the .* jpiAnyKey jsonpath selector seems incorrect.
>
> ```
> select jsonb_path_query('[1,2,3]', '$.*');
> jsonb_path_query
> ------------------
> (0 rows)
>
> select jsonb_path_query('[1,2,3,{"b": [3,4,5]}]', '$.*');
> jsonb_path_query
> ------------------
> [3, 4, 5]
> ```
>
> The first example might be expected, since .* is intended for object keys,
> but the handing of `jpiAnyKey` has a branch for unwrapping arrays. The
> second example, however, just seems weird: this is .*, not .**.
>
This seems to be working correctly. Lax mode causes the first array level
to unwrap and produce new context item values. Then the wildcard member
accessor is applied to each. Numbers don’t have members so no matches
exist in the first example. The object in the second indeed has a single
member and so matches the wildcard and its value, the array, is returned.
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | Wolfgang Walther | 2024-06-04 16:30:07 | Re: Build with LTO / -flto on macOS |
Previous Message | David E. Wheeler | 2024-06-04 16:07:00 | Patch bug: Fix jsonpath .* on Arrays |