On Fri, Mar 14, 2014 at 9:21 PM, Tomas Vondra <tv@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