Re: [HACKERS] [PATCH] Generic type subscripting

> st 9. 9. 2020 v 23:04 Justin Pryzby <pryzby@telsasoft.com> wrote:
>
> This seems to already hit a merge conflict (8febfd185).
> Would you re-rebase ?

Thanks. Sure, will post a rebased version soon.

> On Tue, Sep 15, 2020 at 08:42:40PM +0200, Pavel Stehule wrote:
>
> Maybe I found a another issue.
>
> create table foo(a jsonb);
>
> postgres=# select * from foo;
> ┌───────────────────────────────────────────────────────────────────┐
> │                                 a                                 │
> ╞═══════════════════════════════════════════════════════════════════╡
> │ [0, null, null, null, null, null, null, null, null, null, "ahoj"] │
> └───────────────────────────────────────────────────────────────────┘
> (1 row)
>
> It is working like I expect
>
> but
>
> postgres=# truncate foo;
> TRUNCATE TABLE
> postgres=# insert into foo values('[]');
> INSERT 0 1
> postgres=# update foo set a[10] = 'ahoj';
> UPDATE 1
> postgres=# select * from foo;
> ┌──────────┐
> │    a     │
> ╞══════════╡
> │ ["ahoj"] │
> └──────────┘
> (1 row)

Thanks for looking at the last patch, I appreciate! The situation you've
mention is an interesting edge case. If I understand correctly, the
first example is the result of some operations leading to filling gaps
between 0 and "ahoj". In the second case there is no such gap that's why
nothing was "filled in", although one could expect presence of a "start
position" and fill with nulls everything from it to the new element, is
that what you mean?