Horton

Re: [HACKERS] [PATCH] Generic type subscripting

Pavel Stehule <pavel.stehule@gmail.com>

View thread View on postgr.es
From: Pavel Stehule <pavel.stehule@gmail.com>
To: Dmitry Dolgov <9erthalion6@gmail.com>
Cc: Oleksandr Shulgin <oleksandr.shulgin@zalando.de>, Artur Zakirov <a.zakirov@postgrespro.ru>, Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>, Andres Freund <andres@anarazel.de>, Michael Paquier <michael.paquier@gmail.com>, Oleg Bartunov <obartunov@gmail.com>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, David Steele <david@pgmasters.net>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2018-11-07T16:09:13Z
Lists: pgsql-hackers 
st 7. 11. 2018 v 16:25 odesílatel Dmitry Dolgov <9erthalion6@gmail.com>
napsal:

> > On Fri, 12 Oct 2018 at 07:52, Pavel Stehule <pavel.stehule@gmail.com>
> wrote:
> >
> >> > postgres=# insert into test(v) values( '[]');
> >> > INSERT 0 1
> >> > postgres=# update test set v[1000] = 'a';
> >> > UPDATE 1
> >> > postgres=# update test set v[1000] = 'a';
> >> > UPDATE 1
> >> > postgres=# update test set v[1000] = 'a';
> >> > UPDATE 1
> >> > postgres=# select * from test;
> >> > ┌────┬─────────────────┐
> >> > │ id │        v        │
> >> > ╞════╪═════════════════╡
> >> > │    │ ["a", "a", "a"] │
> >> > └────┴─────────────────┘
> >> > (1 row)
> >> >
> >> > It should to raise exception in this case. Current behave allows
> append simply, but can be source of errors. For this case we can introduce
> some special symbol - some like -0 :)
> >>
> >> Yeah, it may look strange, but there is a reason behind it. I tried to
> keep the
> >> behaviour of this feature consistent with jsonb_set function (and in
> fact
> >> they're sharing the same functionality). And for jsonb_set it's
> documented:
> >>
> >>     If the item (of a path, in our case an index) is out of the range
> >>     -array_length .. array_length -1, and create_missing is true, the
> new value
> >>     is added at the beginning of the array if the item is negative, and
> at the
> >>     end of the array if it is positive.
> >>
> >> So, the index 1000 is way above the end of the array v, and every new
> item has
> >> being appended at the end.
> >>
> >> Of course no one said that they should behave similarly, but I believe
> it's
> >> quite nice to have consistency here. Any other opinions?
> >
> >
> > Aha - although I understand to your motivation, I am think so it is bad
> design - and jsonb_set behave is not happy.
> >
> > I am think so it is wrong idea, because you lost some information -
> field position - I push value on index 10, but it will be stored on second
> position.
>
> The thing is that we don't store the field position in this sense anyway in
> jsonb. For arrays there are dimentions, boundaries and null bitmaps
> stored, but
> for jsonb it's just an array of elements. If we want to store this data, we
> either have to change the format, or fill in a jsonb with null values up
> to the
> required position (the first option is out of the scope of this patch, the
> second doesn't sound that good).
>

I don't agree. If we use a  same syntax for some objects types, we should
to enforce some consistency.

I don't think so you should to introduce nulls for JSONs. In this case, the
most correct solution is raising a exception.

Regards

Pavel

Commits

  1. Throw error when assigning jsonb scalar instead of a composite object

  2. Filling array gaps during jsonb subscripting

  3. Implementation of subscripting for jsonb

  4. Allow ALTER TYPE to update an existing type's typsubscript value.

  5. Allow subscripting of hstore values.

  6. Support subscripting of arbitrary types, not only arrays.

  7. jit: Reference function pointer types via llvmjit_types.c.

  8. Teach contain_leaked_vars that assignment SubscriptingRefs are leaky.

  9. jit: Correct parameter type for generated expression evaluation functions.

  10. Renaming for new subscripting mechanism

  11. Fix assertion failure for SSL connections.

  12. Teach eval_const_expressions() to handle some more cases.