Re: jsonb array-style subscripting
От | Tom Lane |
---|---|
Тема | Re: jsonb array-style subscripting |
Дата | |
Msg-id | 2486.1439849276@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: jsonb array-style subscripting (Peter Geoghegan <pg@heroku.com>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: