> On Tue, Dec 22, 2020 at 11:57:13AM -0500, Tom Lane wrote: > Dmitry Dolgov <9erthalion6@gmail.com> writes: > > On Tue, Dec 22, 2020 at 12:19:26PM +0100, Pavel Stehule wrote: > >> I expect behave like > >> > >> update x set test[1] = 10; --> "[10]"; > >> update x set test['1'] = 10; --> "{"1": 10}" > > > Yes, I also was thinking about this because such behaviour is more > > natural. > > I continue to feel that this is a fundamentally bad idea that will > lead to much more pain than benefit. People are going to want to > know why "test[1.0]" doesn't act like "test[1]". They are going > to complain because "test[$1]" acts so much differently depending > on whether they assigned a type to the $1 parameter or not. And > they are going to bitch because dumping and reloading a rule causes > it to do something different than it did before --- or at least we'd > be at horrid risk of that; only if we hide the injected cast-to-text > doesd the dumped rule look the way it needs to. Even then, the whole > thing is critically dependent on the fact that integer-type constants > are written and displayed differently from other constants, so it > won't scale to any other type that someone might want to treat specially. > So you're just leading datatype designers down a garden path that will be > a dead end for many of them. > > IMO this isn't actually any saner than your previous iterations > on the idea.
Ok. While I don't have any preferences here, we can disregard the last posted patch (extended-with-subscript-type) and consider only v38-0001-Subscripting-for-jsonb version.
There are two parts - fetching and setting.
Probably there can be an agreement on fetching part: if index text is JSONPath expression, use jsonb_path_query, else use jsonb_extract_path.
The setting should be the same in the inverse direction.
I like the behavior of jsonb_extract_path - it has intuitive behaviour and we should use it.