Re: remaining sql/json patches
amit <amitlangote09@gmail.com>
Commits
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
SQL/JSON: Various improvements to SQL/JSON query function docs
- ce416fadb4b6 17.0 landed
- 42de72fa7b80 18.0 landed
-
SQL/JSON: Fix some obsolete comments.
- 290a6d800d90 17.0 landed
- 7768b6569de9 16.4 landed
- 3a8a1f3254b2 18.0 landed
-
SQL/JSON: Fix issues with DEFAULT .. ON ERROR / EMPTY
- c0fc0751862d 17.0 landed
-
JSON_TABLE: Add support for NESTED paths and columns
- bb766cde63b4 17.0 landed
-
Fix JsonExpr deparsing to emit QUOTES and WRAPPER correctly
- f6a2529920cf 17.0 landed
-
Fix typo introduced in 6185c9737
- 2f6e78b0619a 17.0 landed
-
Add basic JSON_TABLE() functionality
- de3600452b61 17.0 landed
-
Avoid splitting errmsg string to span multiple lines
- 085e759e9da7 17.0 landed
-
Add SQL/JSON query functions
- 6185c9737cf4 17.0 landed
-
Implement various jsonpath methods
- 66ea94e8e606 17.0 cited
-
Add soft error handling to some expression nodes
- aaaf9449ec6b 17.0 landed
- 7fbc75b26ed8 17.0 landed
-
Adjust populate_record_field() to handle errors softly
- 1edb3b491bee 17.0 landed
-
Refactor code used by jsonpath executor to fetch variables
- faa2b953ba3b 17.0 landed
-
Test EXPLAIN (FORMAT JSON) ... XMLTABLE
- 752533d40fd5 17.0 landed
-
Simplify productions for FORMAT JSON [ ENCODING name ]
- d3fe6e90bab5 17.0 landed
-
Add trailing commas to enum definitions
- 611806cd726f 17.0 cited
-
doc: add missing <returnvalue> and whitespace
- e055b6be7ebb 17.0 landed
-
Add more SQL/JSON constructor functions
- 03734a7fed7d 17.0 landed
-
Rename a nonterminal used in SQL/JSON grammar
- 254ac5a7c31f 17.0 landed
-
Some refactoring to export json(b) conversion functions
- b22391a2ff7b 17.0 landed
-
Don't include CaseTestExpr in JsonValueExpr.formatted_expr
- 66a9003e2e3e 16.0 landed
- b6e1157e7d33 17.0 landed
-
Code review for commit b6e1157e7d
- 7c7412cae3ea 17.0 landed
-
Pass constructName to transformJsonValueExpr()
- 7825a1b01e40 16.0 landed
- 785480c9533d 17.0 landed
-
Unify JSON categorize type API and export for external use
- 3c152a27b063 17.0 landed
-
Make some indentation in gram.y consistent
- 5edf438eeb00 17.0 landed
- 01f1f789df56 16.0 landed
-
Allow most keywords to be used as column labels without requiring AS.
- 06a7c3154f5b 14.0 cited
-
Reduce size of backend scanner's tables.
- 7f380c59f800 13.0 cited
-
Use perfect hashing, instead of binary search, for keyword lookup.
- c64d0cd5ce24 12.0 cited
Attachments
- v39-0002-Show-function-name-in-TableFuncScan.patch (application/octet-stream) patch v39-0002
- v39-0003-JSON_TABLE.patch (application/octet-stream) patch v39-0003
- v39-0001-Add-SQL-JSON-query-functions.patch (application/octet-stream) patch v39-0001
On Wed, Jan 24, 2024 at 10:11 PM Amit Langote <amitlangote09@gmail.com> wrote:
> On Tue, Jan 23, 2024 at 12:46 AM jian he <jian.universality@gmail.com> wrote:
> > On Mon, Jan 22, 2024 at 10:28 PM Amit Langote <amitlangote09@gmail.com> wrote:
> > >
> > > > based on v35.
> > > > Now I only applied from 0001 to 0007.
> > > > For {DEFAULT expression ON EMPTY} | {DEFAULT expression ON ERROR}
> > > > restrict DEFAULT expression be either Const node or FuncExpr node.
> > > > so these 3 SQL/JSON functions can be used in the btree expression index.
> > >
> > > I'm not really excited about adding these restrictions into the
> > > transformJsonFuncExpr() path. Index or any other code that wants to
> > > put restrictions already have those in place, no need to add them
> > > here. Moreover, by adding these restrictions, we might end up
> > > preventing users from doing useful things with this like specify
> > > column references. If there are semantic issues with allowing that,
> > > we should discuss them.
> > >
> >
> > after applying v36.
> > The following index creation and query operation works. I am not 100%
> > sure about these cases.
> > just want confirmation, sorry for bothering you....
>
> No worries; I really appreciate your testing and suggestions.
>
> > drop table t;
> > create table t(a jsonb, b int);
> > insert into t select '{"hello":11}',1;
> > insert into t select '{"hello":12}',2;
> > CREATE INDEX t_idx2 ON t (JSON_query(a, '$.hello1' RETURNING int
> > default b + random() on error));
> > CREATE INDEX t_idx3 ON t (JSON_query(a, '$.hello1' RETURNING int
> > default random()::int on error));
> > create or replace function ret_setint() returns setof integer as
> > $$
> > begin
> > -- perform pg_sleep(0.1);
> > return query execute 'select 1 union all select 1';
> > end;
> > $$
> > language plpgsql IMMUTABLE;
> > SELECT JSON_query(a, '$.hello1' RETURNING int default ret_setint() on
> > error) from t;
> > SELECT JSON_query(a, '$.hello1' RETURNING int default sum(b) over()
> > on error) from t;
> > SELECT JSON_query(a, '$.hello1' RETURNING int default sum(b) on
> > error) from t group by a;
> >
> > but the following cases will fail related to index and default expression.
> > create table zz(a int, b int);
> > CREATE INDEX zz_idx1 ON zz ( (b + random()::int));
> > create table ssss(a int, b int default ret_setint());
> > create table ssss(a int, b int default sum(b) over());
>
> I think your suggestion to add restrictions on what is allowed for
> DEFAULT makes sense. Also, immutability shouldn't be checked in
> transformJsonBehavior(), but in contain_mutable_functions() as done in
> the attached. Added some tests too.
>
> I still need to take a look at your other report regarding typmod but
> I'm out of energy today.
The attached updated patch should address one of the concerns --
JSON_QUERY() should now work appropriately with RETURNING type with
typmod whether or OMIT QUOTES is specified.
But I wasn't able to address the problems with RETURNING
record_type_with_typmod, that is, the following example you shared
upthread:
create domain char3_domain_not_null as char(3) NOT NULL;
create domain hello as text not null check (value = 'hello');
create domain int42 as int check (value = 42);
create type comp_domain_with_typmod AS (a char3_domain_not_null, b int42);
select json_value(jsonb'{"rec": "(abcd,42)"}', '$.rec' returning
comp_domain_with_typmod);
json_value
------------
(1 row)
select json_value(jsonb'{"rec": "(abcd,42)"}', '$.rec' returning
comp_domain_with_typmod error on error);
ERROR: value too long for type character(3)
select json_value(jsonb'{"rec": "abcd"}', '$.rec' returning
char3_domain_not_null error on error);
json_value
------------
abc
(1 row)
The problem with returning comp_domain_with_typmod from json_value()
seems to be that it's using a text-to-record CoerceViaIO expression
picked from JsonExpr.item_coercions, which behaves differently than
the expression tree that the following uses:
select ('abcd', 42)::comp_domain_with_typmod;
row
----------
(abc,42)
(1 row)
I don't see a good way to make RETURNING record_type_with_typmod to
work cleanly, so I am inclined to either simply disallow the feature
or live with the limitation.
--
Thanks, Amit Langote
EDB: http://www.enterprisedb.com