Re: [HACKERS] [PATCH] Generic type subscripting

pá 18. 9. 2020 v 13:01 odesílatel Dmitry Dolgov <9erthalion6(at)gmail(dot)com>
napsal:

> > 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.
>

This is a relatively new interface and at this moment we can decide if it
will be consistent or not. I have not a problem if I have different
functions with different behaviors, but I don't like one interface with
slightly different behaviors for different types. I understand your
argument about implementing a lighter interface to some existing API. But I
think so more important should be consistency in maximall possible rate
(where it has sense).

For me "jsonb" can be a very fundamental type in PLpgSQL development - it
can bring a lot of dynamic to this environment (it can work perfectly like
PL/SQL collection or like Perl dictionary), but for this purpose the
behaviour should be well consistent without surprising elements.

Regards

Pavel