On Fri, Mar 14, 2014 at 9:21 PM, Tomas Vondra <t...@fuzzy.cz> wrote: > I'm not awfully familiar with the GIN code, but based on Alexander's > feedback I presume fixing the GIN length limit (or rather removing it, > as it's a feature, not a bug) is quite straightforward. Why not to at > least consider that for 9.4, unless it turns more complex than expected? > > Don't get me wrong - I'm aware it's quite late in the last commitfest, > and if it's deemed unacceptable / endandering 9.4 release, I'm not going > to say a word. But if it's a simple patch ...
Well I think the bigger picture is that the cases were we're getting this error it's because we're expecting too much from the GIN opclass. It's trying to index entire json objects as individual values which isn't really very useful. We're unlikely to go querying for rows where the value of a given key is a specific json object. As I understand it Peter's right that in its current form the GIN opclass is only useful if you use it on an expression index on specific pieces of your json which are traditional non-nested hash tables. Or I suppose if you're really only concerned with the ? operator which looks for keys, which is pretty common too. I had in mind that the GIN opclass would do something clever like decompose the json into all the path->value tuples so I could do arbitrary path lookups for values. That might be possible in the future but it's not what we have today and what we have today is already better than hstore. I think we're better off committing this and moving forward with the contrib hstore2 wrapper which uses this infrastructure so people have a migration path. I don't think Josh is right to say it'll be "fixed" in 9.5. It'll be "better" in 9.5 because we have ambitious plans to continue improving in this direction. But it'll be even better in 9.6 and better again in 9.7. It'll never be "fixed". -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
