Re: SQL:2023 JSON simplified accessor support

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>, Alexandra Wang <alexandra(dot)wang(dot)oss(at)gmail(dot)com>, Nikita Glukhov <glukhov(dot)n(dot)a(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, "David E(dot) Wheeler" <david(at)justatheory(dot)com>, jian he <jian(dot)universality(at)gmail(dot)com>
Subject: Re: SQL:2023 JSON simplified accessor support
Date: 2024-11-26 09:12:06
Message-ID: 21fa36b4-6d56-4556-b524-9e3955b922c8@eisentraut.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 21.11.24 23:46, Andrew Dunstan wrote:
>> Questions:
>>
>> 1. Since Nikita’s patches did not address the JSON data type, and JSON
>> currently does not support subscripting, should we limit the initial
>> feature set to JSONB dot-notation for now? In other words, if we aim
>> to fully support JSON simplified accessors for the plain JSON type,
>> should we handle support for plain JSON subscripting as a follow-up
>> effort?
>>
>> 2. I have yet to have a more thorough review of Nikita’s patches.
>> One area I am not familiar with is the hstore-related changes. How
>> relevant is hstore to the JSON simplified accessor?
>>
>
> We can't change the way the "->" operator works, as there could well be
> uses of it in the field that rely on its current behaviour. But maybe we
> could invent a new operator which is compliant with the standard
> semantics for dot access, and call that. Then we'd get the best
> performance, and also we might be able to implement it for the plain
> JSON type. If that proves not possible we can think about not
> implementing for plain JSON, but I'd rather not go there until we have to.

Yes, I think writing a custom operator that is similar to "->" but has
the required semantics is the best way forward. (Maybe it can be just a
function?)

> I don't think we should be including hstore changes here - we should
> just be aiming at implementing the standard for JSON access. hstore
> changes if any should be a separate feature. The aren't relevant to JSON
> access, although they might use some of the same infrastructure,
> depending on implementation.

In a future version, the operator/function mentioned above could be a
catalogued property of a type, similar to typsubscript. Then you could
also apply this to other types. But let's leave that for later.

If I understand it correctly, Nikita's patch uses the typsubscript
support function to handle both bracket subscripting and dot notation.
I'm not sure if it's right to mix these two together. Maybe I didn't
understand that correctly.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dmitry Nikitin 2024-11-26 09:24:37 Re: [PATCH] Missing Assert in the code
Previous Message Zhijie Hou (Fujitsu) 2024-11-26 08:18:40 RE: Conflict detection for update_deleted in logical replication