Re: SQL/JSON: JSON_TABLE
От | Andrew Dunstan |
---|---|
Тема | Re: SQL/JSON: JSON_TABLE |
Дата | |
Msg-id | cb6ce329-2899-9a2c-80d9-62284f2e570f@dunslane.net обсуждение исходный текст |
Ответ на | Re: SQL/JSON: JSON_TABLE (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: SQL/JSON: JSON_TABLE
Re: SQL/JSON: JSON_TABLE |
Список | pgsql-hackers |
On 3/24/22 18:54, Andrew Dunstan wrote: > On 3/5/22 09:35, Andrew Dunstan wrote: >> On 3/4/22 15:05, Andrew Dunstan wrote: >>> On 3/4/22 13:13, Erikjan Rijkers wrote: >>>> Op 04-03-2022 om 17:33 schreef Andrew Dunstan: >>>>> This set of patches deals with items 1..7 above, but not yet the ERROR >>>>> ON ERROR issue. It also makes some message cleanups, but there is more >>>>> to come in that area. >>>>> >>>>> It is based on the latest SQL/JSON Functions patch set, which does not >>>>> include the sql_json GUC patch. >>>>> >>>>> [0001-SQL-JSON-functions-without-sql_json-GUC-v56.patch] >>>>> [0002-JSON_TABLE-v56.patch] >>>>> [0003-JSON_TABLE-PLAN-DEFAULT-clause-v56.patch] >>>>> [0004-JSON_TABLE-PLAN-clause-v56.patch] >>>> Hi, >>>> >>>> I quickly tried the tests I already had and there are two statements >>>> that stopped working: >>>> >>>> testdb=# SELECT JSON('{"a": 123, "b": [true, "foo"], "a2": "bar"}' >>>> RETURNING jsonb); >>>> ERROR: syntax error at or near "RETURNING" >>>> LINE 1: ...SON('{"a": 123, "b": [true, "foo"], "a2": "bar"}' RETURNING >>>> ... >>>> >>>> testdb=# select JSON_SCALAR(123.45 returning jsonb); >>>> ERROR: syntax error at or near "returning" >>>> LINE 1: select JSON_SCALAR(123.45 returning jsonb) >>>> >>>> (the '^' pointer in both cases underneath 'RETURNING' >>>> >>>> >>>> >>> Yes, you're right, that was implemented as part of the GUC patch. I'll >>> try to split that out and send new patchsets with the RETURNING clause >>> but without the GUC (see upthread for reasons) >>> >>> >> Here's a patchset with RETURNING for JSON() and JSON_SCALAR() but >> without the GUC >> > Here's a new set with the latest sql/json functions patch and fixes for > some further node handling inadequacies. > > I have been wrestling with the docs in these patches, which are somewhat haphazardly spread across the various patches, and tying myself up in knots. Fixing them so I don't cause later merge pain is difficult. I'm therefore going to commit this series (staggered as previously requested) without documentation and then commit a consolidated documentation patch for them. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: