Re: [HACKERS] [PATCH] Generic type subscripting

Поиск
Список
Период
Сортировка
От Dmitry Dolgov
Тема Re: [HACKERS] [PATCH] Generic type subscripting
Дата
Msg-id 20200918110204.77yu4ioqlhhfhcya@localhost
обсуждение исходный текст
Ответ на Re: [HACKERS] [PATCH] Generic type subscripting  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: [HACKERS] [PATCH] Generic type subscripting
Список pgsql-hackers
> On Thu, Sep 17, 2020 at 05:19:19PM +0200, Pavel Stehule wrote:
>
> ok, then I think we can design some workable behaviour
>
> My first rule - there should not be any implicit action that shifts
> positions in the array. It can be explicit, but not implicit. It is true
> for positive indexes, and it should be true for negative indexes too.
>
> then I think so some like this can work
>
> if (idx < 0)
> {
>   if (abs(idx) > length of array)
>     exception("index is of of range");
>   array[length of array - idx] := value;
> }
> else
> {
>    /* known behave for positive index */
> }

In this way (returning an error on a negative indices bigger than the
number of elements) functionality for assigning via subscripting will be
already significantly differ from the original one via jsonb_set. Which
in turn could cause a new wave of something similar to "why assigning an
SQL NULL as a value returns NULL instead of jsonb?". Taking into account
that this is not absolutely new interface, but rather a convenient
shortcut for the existing one it probably makes sense to try to find a
balance between both consistency with regular array and similarity with
already existing jsonb modification functions.

Having said that, my impression is that this balance should be not fully
shifted towards consistensy with the regular array type, as jsonb array
and regular array are fundamentally different in terms of
implementation. If any differences are of concern, they should be
addressed at different level. At the same time I've already sort of gave
up on this patch in the form I wanted to see it anyway, so anything goes
if it helps bring it to the finish point. In case if there would be no
more arguments from other involved sides, I can post the next version
with your suggestion included.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Juan José Santamaría Flecha
Дата:
Сообщение: Re: BUG #15858: could not stat file - over 4GB
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: WIP: BRIN multi-range indexes