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.
