From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Himanshu Upadhyaya <upadhyaya(dot)himanshu(at)gmail(dot)com> |
Cc: | Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, Oleg Bartunov <obartunov(at)postgrespro(dot)ru>, Erik Rijkers <er(at)xs4all(dot)nl> |
Subject: | Re: SQL/JSON: functions |
Date: | 2022-03-05 14:39:05 |
Message-ID: | 1d44d832-4ea9-1ec9-81e9-bc6b2bd8cc43@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 3/4/22 11:28, Andrew Dunstan wrote:
> On 3/2/22 10:19, Andrew Dunstan wrote:
>> On 3/1/22 16:41, Andrew Dunstan wrote:
>>> On 2/1/22 14:11,I wrote:
>>>> 2. The new GUC "sql_json" is a bit of a worry. I understand what it's
>>>> trying to do, but I'm trying to convince myself it's not going to be a
>>>> fruitful source of error reports, especially if people switch it in the
>>>> middle of a session. Maybe it should be an initdb option instead of a GUC?
>>>>
>>>>
>>> So far my efforts have not borne fruit. Here's why:
>>>
>>>
>>> andrew=# set sql_json = jsonb;
>>> SET
>>> andrew=# create table abc (x text, y json);
>>> CREATE TABLE
>>> andrew=# \d abc
>>> Table "public.abc"
>>> Column | Type | Collation | Nullable | Default
>>> --------+------+-----------+----------+---------
>>> x | text | | |
>>> y | json | | |
>>>
>>> andrew=# insert into abc values ('a','{"q":1}');
>>> INSERT 0 1
>>> andrew=# select json_each(y) from abc;
>>> ERROR: function json_each(json) does not exist
>>> LINE 1: select json_each(y) from abc;
>>> ^
>>> HINT: No function matches the given name and argument types. You might
>>> need to add explicit type casts.
>>> andrew=# select jsonb_each(y) from abc;
>>> jsonb_each
>>> ------------
>>> (q,1)
>>> (1 row)
>>>
>>>
>>> The description tells them the column is json, but the json_* functions
>>> don't work on the column and you need to use the jsonb functions. That
>>> seems to me a recipe for major confusion. It might be better if we set
>>> it at initdb time so it couldn't be changed, but even so it could be
>>> horribly confusing.
>>>
>>> This is certainly severable from the rest of these patches. I'm not sure
>>> how severable it is from the SQL/JSON Table patches.
>>>
>>>
>> I have confirmed that this is not required at all for the JSON_TABLE
>> patch set.
>>
>>
>> I'll submit new patch sets omitting it shortly. The GUC patch can be
>> considered separately, probably as release 16 material, but I think as
>> is it's at best quite incomplete.
>
> here's a new set of patches, omitting the GUC patch and with the
> beginnings of some message cleanup - there's more work to do there.
>
>
This patchset restores the RETURNING clause for JSON() and JSON_SCALAR()
but without the GUC
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
Attachment | Content-Type | Size |
---|---|---|
0001-Common-SQL-JSON-clauses-v64.patch | text/x-patch | 30.8 KB |
0002-SQL-JSON-constructors-v64.patch | text/x-patch | 186.8 KB |
0003-IS-JSON-predicate-v64.patch | text/x-patch | 54.5 KB |
0004-SQL-JSON-query-functions-v64.patch | text/x-patch | 195.7 KB |
0005-SQL-JSON-functions-for-json-type-v64.patch | text/x-patch | 57.0 KB |
0006-RETURNING-clause-for-JSON-and-JSON_SCALAR-v64.patch | text/x-patch | 8.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-03-05 15:12:20 | Re: [PoC] Let libpq reject unexpected authentication requests |
Previous Message | Andrew Dunstan | 2022-03-05 14:35:23 | Re: SQL/JSON: JSON_TABLE |