Peter Eisentraut <peter.eisentr...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers