Re: SQL:2023 JSON simplified accessor support
От | Peter Eisentraut |
---|---|
Тема | Re: SQL:2023 JSON simplified accessor support |
Дата | |
Msg-id | 21fa36b4-6d56-4556-b524-9e3955b922c8@eisentraut.org обсуждение исходный текст |
Ответ на | Re: SQL:2023 JSON simplified accessor support (Andrew Dunstan <andrew@dunslane.net>) |
Список | 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.
В списке pgsql-hackers по дате отправления: