Re: [HACKERS] [PATCH] Generic type subscripting
Dmitry Dolgov <9erthalion6@gmail.com>
Attachments
> On Tue, Dec 22, 2020 at 12:19:26PM +0100, Pavel Stehule wrote:
>
> > Here is the new version of jsonb subscripting rebased on the committed
> > infrastructure patch. I hope it will not introduce any confusion with
> > the previously posted patched in this thread (about alter type subscript
> > and hstore) as they are independent.
> >
> > There are few differences from the previous version:
> >
> > * No limit on number of subscripts for jsonb (as there is no intrinsic
> > limitation of this kind for jsonb).
> >
> > * In case of assignment via subscript now it expects the replace value
> > to be of jsonb type.
> >
> > * Similar to the implementation for arrays, if the source jsonb is NULL,
> > it will be replaced by an empty jsonb and the new value will be
> > assigned to it. This means:
> >
> > =# select * from test_jsonb_subscript where id = 3;
> > id | test_json
> > ----+-----------
> > 3 | NULL
> >
> > =# update test_jsonb_subscript set test_json['a'] = '1' where id =
> > 3;
> > UPDATE 1
> >
> > =# select * from test_jsonb_subscript where id = 3;
> > id | test_json
> > ----+-----------
> > 3 | {"a": 1}
> >
> > and similar:
> >
> > =# select * from test_jsonb_subscript where id = 3;
> > id | test_json
> > ----+-----------
> > 3 | NULL
> >
> > =# update test_jsonb_subscript set test_json[1] = '1' where id = 3;
> > UPDATE 1
> >
> > =# select * from test_jsonb_subscript where id = 3;
> > id | test_json
> > ----+-----------
> > 3 | {"1": 1}
> >
> > The latter is probably a bit strange looking, but if there are any
> > concerns
> > about this part (and in general about an assignment to jsonb which is
> > NULL)
> > of the implementation it could be easily changed.
> >
>
> What is the possibility to make an array instead of a record?
>
> I expect behave like
>
> update x set test[1] = 10; --> "[10]";
> update x set test['1'] = 10; --> "{"1": 10}"
Yes, I also was thinking about this because such behaviour is more
natural. To implement this we need to provide possibility for type
specific code to remember original subscript expression type (something
like in the attached version), which could be also useful for the future
work on jsonpath. I'm just not sure if there are again some important
bits are missing in this idea, so if someone can take a look I would
appreciate. In case there are any issues, I would just suggest keep it
simple and return NULL.
Commits
-
Throw error when assigning jsonb scalar instead of a composite object
- aa6e46daf530 14.0 landed
-
Filling array gaps during jsonb subscripting
- 81fcc72e6622 14.0 landed
-
Implementation of subscripting for jsonb
- 676887a3b0b8 14.0 landed
-
Allow ALTER TYPE to update an existing type's typsubscript value.
- 8c15a297452e 14.0 landed
-
Allow subscripting of hstore values.
- 0ec5f7e78231 14.0 landed
-
Support subscripting of arbitrary types, not only arrays.
- c7aba7c14efd 14.0 landed
-
jit: Reference function pointer types via llvmjit_types.c.
- df99ddc70b97 14.0 landed
-
Teach contain_leaked_vars that assignment SubscriptingRefs are leaky.
- c0549cee07ea 13.2 landed
- 62ee70331336 14.0 landed
- 3470caa21bf8 10.16 landed
- 2f1997b1551a 12.6 landed
- 1f229f4fdcf8 11.11 landed
- 17c77c8c90f7 9.6.21 landed
-
jit: Correct parameter type for generated expression evaluation functions.
- 5da871bfa1ba 14.0 landed
- 1e16ad101459 11.11 landed
- 27b57f806dc2 12.6 landed
- 01c6370a32e5 13.2 landed
-
Renaming for new subscripting mechanism
- 558d77f20e4e 12.0 landed
-
Fix assertion failure for SSL connections.
- ab69ea9feeb9 12.0 cited
-
Teach eval_const_expressions() to handle some more cases.
- 3decd150a2d5 11.0 cited