Peter Geoghegan <pg@heroku.com> writes:
> This patch does not add an operator at all, actually. If feels like
> there ought to be an operator, but in fact there is not. The parser is
> hard-coded to recognize array-style subscripts, which this uses.
> While I'm certainly glad that Dmitry took the time to work on this, I
> think we will need an operator, too. Or, more accurately, there should
> probably be a way to make something like this use some available GIN
> index:
> postgres=# explain analyze select * from testjsonb where p['a'] = '[1]';
Hm. There is definitely attraction to the idea that x[y] is some sort of
operator-like syntactic sugar for invocation of an underlying function,
rather than necessarily a hard-coded behavior. That would provide a
framework for extending the feature to all container-like datatypes,
whereas the approach Dimitry has prototyped doesn't look like it offers
much help at all for other datatypes.
But I do not think that that will change things very much as far as
making it possible for things like the above to be indexed. You'd
still have an expression tree that's a nest of two operators, which
doesn't fit into our ideas about index opclasses. (That is, it still
has to be a special case, so it doesn't matter that much if one of
the nodes is some kind of NotAnArrayRef rather than a FuncExpr with
some new CoercionForm value to make it print differently.)
Also, the syntactic sugar would have to be able to deal with multiple
subscripts, which makes things a lot more complicated.
regards, tom lane
