Re: Patch bug: Fix jsonpath .* on Arrays

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.

In response to

Responses

Browse pgsql-hackers by date

  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