Re: SQL:2023 JSON simplified accessor support

Поиск
Список
Период
Сортировка
От Chao Li
Тема Re: SQL:2023 JSON simplified accessor support
Дата
Msg-id 3EF2F248-1881-4764-96D7-CC0957AC68F7@gmail.com
обсуждение исходный текст
Ответ на Re: SQL:2023 JSON simplified accessor support  (Alexandra Wang <alexandra.wang.oss@gmail.com>)
Ответы Re: SQL:2023 JSON simplified accessor support
Список pgsql-hackers
Дерево обсуждения

Best,
Alex
<v14-0002-Allow-Generic-Type-Subscripting-to-Accept-Dot-No.patch><v14-0003-Export-jsonPathFromParseResult.patch><v14-0001-Allow-transformation-of-only-a-sublist-of-subscr.patch><v14-0005-Implement-read-only-dot-notation-for-jsonb.patch><v14-0007-Implement-jsonb-wildcard-member-accessor.patch><v14-0006-Implement-Jsonb-subscripting-with-slicing.patch><v14-0004-Extract-coerce_jsonpath_subscript.patch>

I am trying to split different topics to different email to keep every issue to be focused.

I also have a suggestion.

If I do:

```
— s1
select (t.data)['con']['a'][1]['b']['c']['d'] from test_jsonb_types t;

—s2
select (t.data).con.a[1].b['c'].d from test_jsonb_types t;
```

The two statements are actually identical. But they generate quite different rewritten query trees. S1’s rewritten tree is much simpler than s2’s. However, their plan trees are the same.

I think we can convert string indirections to indices indirection first before transform indirections, so that the two SQLs will generate the same rewritten query tree, which would simplify the code logic of rewriting query tree and the planner.


Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/




В списке pgsql-hackers по дате отправления: