MIME-Version: 1.0
In-Reply-To: 
 <CAM3SWZTerM-f8nhmuatR-YhPiMwrqR01=TwtCNM1E9PERkvAAA@mail.gmail.com>
References: <16769.1399407530@sss.pgh.pa.us>
 <20140506212020.GK30817@momjian.us>
 <57E8AA44-F816-45F2-BB61-5A854FFB0A97@justatheory.com>
 <28554.1399414853@sss.pgh.pa.us>
 <20140508134701.GO30817@momjian.us> <5819.1399558614@sss.pgh.pa.us>
 <1888.1399588751@sss.pgh.pa.us> <20140509033405.GA23254@momjian.us>
 <536C550F.50108@archidevsys.co.nz> <18360.1399633457@sss.pgh.pa.us>
 <20140509135336.GC23254@momjian.us>
 <CAM-w4HOQ+ynm70Cgr4BwMqMc0jfL_8EZAwG2UD6r=EehjH3OOw@mail.gmail.com>
 <28961.1399668272@sss.pgh.pa.us> <536E8F3A.40706@vmware.com>
 <CAM3SWZTerM-f8nhmuatR-YhPiMwrqR01=TwtCNM1E9PERkvAAA@mail.gmail.com>
Date: Sat, 10 May 2014 17:25:49 -0700
Message-ID: 
 <CAM3SWZQpg8cX+MccHd38KCQMgD9Leh-4BNBFnV-8gh5+Rnb1Hg@mail.gmail.com>
Subject: Re: default opclass for jsonb (was Re: Call for
 GIST/GIN/SP-GIST opclass documentation)
From: Peter Geoghegan <pg@heroku.com>
To: Heikki Linnakangas <hlinnakangas@vmware.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Greg Stark <stark@mit.edu>,
 Bruce Momjian <bruce@momjian.us>,
 Gavin Flower <GavinFlower@archidevsys.co.nz>,
 "David E. Wheeler" <david@justatheory.com>,
 Robert Haas <robertmhaas@gmail.com>, Andrew Dunstan <andrew@dunslane.net>,
 "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Content-Type: multipart/mixed; boundary=001a1134a45c6c22ed04f914df32
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

--001a1134a45c6c22ed04f914df32
Content-Type: text/plain; charset=UTF-8

On Sat, May 10, 2014 at 2:52 PM, Peter Geoghegan <pg@heroku.com> wrote:
> I've added a wildcard to the rhs jsonb here, which of course won't
> work, the proximate cause being that that simply isn't valid jsonb.
> It's also something inherently impossible to support with the current
> jsonb_hash_op's indexing strategy. That only hashes elements and
> values, mixing in keys from all outer nesting levels (so it's possible
> for there to be 0 *nentries).

It occurs to me that this could be a particular problem for
jsonb_hash_ops. Consider this jsonb:

'{"a":{}}'::jsonb

In one sense, the outermost level's "a" key does have a value: an
empty object. So we may test containment in an indexable fashion like
this:

select * from foo where j @> '{"a":{}}'::jsonb

But in another sense, the sense that is relevant to jsonb_hash_ops, it
does not. There would be *no* GIN keys passed back from
gin_extract_jsonb_hash() if it were tasked with extracting keys from
this rhs jsonb.

Now, I'm not all that worried about this, because this is surely an
odd-ball use case, particularly for jsonb_hash_ops where no keys are
separately indexed (separately from *primitive* elements/values).
However, it is worth noting in the documentation in my view. I attach
a doc patch that adds this.

-- 
Peter Geoghegan

--001a1134a45c6c22ed04f914df32
Content-Type: text/x-patch; charset=US-ASCII;
 name="jsonb_structure_containment.patch"
Content-Disposition: attachment; filename="jsonb_structure_containment.patch"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_hv1lm9am0

KioqIGEvZG9jL3NyYy9zZ21sL2pzb24uc2dtbAotLS0gYi9kb2Mvc3JjL3Nn
bWwvanNvbi5zZ21sCioqKioqKioqKioqKioqKiBTRUxFQ1QgamRvYy0mZ3Q7
J2d1aWQnLCBqZG9jLSZndDsnbmFtZScKKioqIDQ1Myw0NTggKioqKgotLS0g
NDUzLDQ2MyAtLS0tCiAgICAgIHBhcnRpY3VsYXJseSB3aGVuIHF1ZXJpZXMg
Y29udGFpbiBrZXlzIHRoYXQgYXBwZWFyIGZyZXF1ZW50bHkgaW4gdGhlCiAg
ICAgIGRhdGEuICBUaGVyZWZvcmUgc2VhcmNoIG9wZXJhdGlvbnMgdHlwaWNh
bGx5IHBlcmZvcm0gYmV0dGVyCiAgICAgIHRoYW4gd2l0aCB0aGUgZGVmYXVs
dCBvcGVyYXRvciBjbGFzcy4KKyAgICAgPGxpdGVyYWw+anNvbmJfaGFzaF9v
cHM8L2xpdGVyYWw+IGluZGV4ZXMgYXJlIGlsbC1zdWl0ZWQgdG8gY2FzZXMK
KyAgICAgd2hlcmUgdGhlcmUgYXJlIGZyZXF1ZW50IGNvbnRhaW5tZW50IHF1
ZXJpZXMgdGhhdCB0ZXN0IGNvbnRhaW5tZW50CisgICAgIG9mIGEgPHR5cGU+
anNvbmI8Lz4gPGVtcGhhc2lzPndpdGhvdXQ8Lz4gYW55IHByaW1pdGl2ZSBv
YmplY3QKKyAgICAgdmFsdWVzIG9yIGFycmF5IGVsZW1lbnRzLCBhcyB3aGVu
IHNlYXJjaGluZyBmb3IgSlNPTiBkb2N1bWVudHMKKyAgICAgbWF0Y2hpbmcg
YSBwYXJ0aWN1bGFyIHN0cnVjdHVyZS4KICAgIDwvcGFyYT4KICAKICAgIDxw
YXJhPgo=

--001a1134a45c6c22ed04f914df32
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

--001a1134a45c6c22ed04f914df32--