@@ -269,6 +269,12 @@ SELECT '"foo"'::jsonb @> '"foo"'::jsonb;
269
269
-- The array on the right side is contained within the one on the left:
270
270
SELECT '[1, 2, 3]'::jsonb @> '[1, 3]'::jsonb;
271
271
272
+ -- Order of array elements is not significant, so this is also true:
273
+ SELECT '[1, 2, 3]'::jsonb @> '[3, 1]'::jsonb;
274
+
275
+ -- Duplicate array elements don't matter either:
276
+ SELECT '[1, 2, 3]'::jsonb @> '[1, 2, 2]'::jsonb;
277
+
272
278
-- The object with a single pair on the right side is contained
273
279
-- within the object on the left side:
274
280
SELECT '{"product": "PostgreSQL", "version": 9.4, "jsonb":true}'::jsonb @> '{"version":9.4}'::jsonb;
@@ -288,8 +294,10 @@ SELECT '{"foo": {"bar": "baz"}}'::jsonb @> '{"bar": "baz"}'::jsonb; -- yields f
288
294
The general principle is that the contained object must match the
289
295
containing object as to structure and data contents, possibly after
290
296
discarding some non-matching array elements or object key/value pairs
291
- from the containing object. However, the order of array elements is
292
- not significant when doing a containment match.
297
+ from the containing object.
298
+ But remember that the order of array elements is not significant when
299
+ doing a containment match, and duplicate array elements are effectively
300
+ considered only once.
293
301
</para>
294
302
295
303
<para>
0 commit comments