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