Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> I see a possible problem here: This design only allows one subscripting
> function. But what you'd really want in this case is at least two: one
> taking an integer type for selecting by array index, and one taking text
> for selecting by field name.
No, I think you're missing the point: there is just one function per
datatype for *parse analysis* of a subscripting operation applied to
that datatype. What it chooses to allow as subscript type, and what
function it determines will be used at execution, is up to it.
I agree that the given jsonb_subscript is failing to handle the
subscript-an-array-with-an-integer case, but that's a datatype-specific
shortcoming not a failure of the overall design.
I would guess that what we really want for jsonb is the ability to
intermix integer and text subscripts, so that jsonbcol['foo'][42]['bar']
would extract the "bar" field of an object in position 42 of an
array in field "foo" of the given jsonb value. So you probably
end up still having one jsonb execution function, not two, and
it would have different code paths depending on whether it sees
the type of the next subscript expression to be integer or text.
> It looks like your jsonb subscripting function just returns null if it
> can't find a field, which is also a bit dubious.
Nah, that seems fine. Our precedent for standard array subscripting is to
return NULL for out-of-range subscripts, and the jsonb -> operator also
returns NULL if there's no such field. It would be rather surprising if
jsonb subscripting threw an error instead; and I do not think it would be
more useful.
regards, tom lane