Re: [HACKERS] [PATCH] Generic type subscripting

From: Dmitry Dolgov <9erthalion6(at)gmail(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Justin Pryzby <pryzby(at)telsasoft(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, David Steele <david(at)pgmasters(dot)net>, Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, David Fetter <david(at)fetter(dot)org>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Oleksandr Shulgin <oleksandr(dot)shulgin(at)zalando(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Oleg Bartunov <obartunov(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] [PATCH] Generic type subscripting
Date: 2020-09-20 15:46:52
Message-ID: 20200920154652.etzmrphoe3hiod7t@localhost
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

> On Fri, Sep 18, 2020 at 07:23:11PM +0200, Pavel Stehule wrote:
> > 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.

And here we are, the rebased version with the following changes:

insert into test_jsonb_subscript values (1, '[]');
update test_jsonb_subscript set test_json[5] = 1;
select * from test_jsonb_subscript;
id | test_json
1 | [null, null, null, null, null, 1]
(1 row)

update test_jsonb_subscript set test_json[-8] = 1;
ERROR: path element at position 1 is out of range: -8

Thanks for the suggestions!

Attachment Content-Type Size
v34-0001-Base-implementation-of-subscripting-mechanism.patch text/x-diff 47.0 KB
v34-0002-Subscripting-for-array.patch text/x-diff 24.8 KB
v34-0003-Subscripting-for-jsonb.patch text/x-diff 34.1 KB
v34-0004-Subscripting-documentation.patch text/x-diff 20.0 KB
v34-0005-Filling-gaps-in-jsonb-arrays.patch text/x-diff 8.0 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Ranier Vilela 2020-09-20 16:50:34 Re: Planner, check if can use consider HASH for groupings (src/backend/optimizer/plan/planner.c)
Previous Message Etsuro Fujita 2020-09-20 14:40:52 Re: problem with RETURNING and update row movement