On Wed, Apr 9, 2014 at 02:22:54PM -0400, Greg Stark wrote: > On Wed, Apr 9, 2014 at 11:24 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> Maybe we should make *neither* of these the default opclass, and give > >> *neither* the name json_ops. > > > > There's definitely something to be said for that. Default opclasses are > > sensible when there's basically only one behavior that's interesting for > > most people. We can already see that that's not going to be the case > > for jsonb indexes, at least not with the currently available alternatives. > > > > Not having a default would force users to make decisions explicitly. > > Is that what we want? > > I don't like the idea of having no default opclass. I think there's a > huge usability gain in being able to "just" create an index on a > column and have it do something reasonable for most use cases. > > I can get behind the idea of having separate index opclasses for paths > and path-value pairs but I suspect the default should just be to index > both in the same index. If we can have one default index opclass that > supports containment and existence and then other opclasses that are > smaller but only support a subset of the operators that would seem > like the best compromise. > > I'm a bit confused by Heikki's list though. I would expect path and > path-value pair to be the only useful ones. I'm not clear what an > index on keys or key-value would be -- it would index just the > top-level keys and values without recursing?
Where are we on the default JSONB opclass change? -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
