feat(ste_vec): add jsonb parameter variants for containment functions

[tobyhede]

Summary

• Add overloaded variants of jsonb_contains and jsonb_contained_by that accept mixed types (eql_v2_encrypted, jsonb)
• Enables queries where one operand is an encrypted column and the other is plain JSONB
• Comprehensive test coverage for all operator/type combinations

New Functions

Function	Parameters
jsonb_contains	(eql_v2_encrypted, jsonb)
jsonb_contains	(jsonb, eql_v2_encrypted)
jsonb_contained_by	(eql_v2_encrypted, jsonb)
jsonb_contained_by	(jsonb, eql_v2_encrypted)

Test Coverage Matrix

14 focused tests covering all operator/type combinations:

Operator	LHS	RHS	Test
jsonb_contains	encrypted	jsonb_param	contains_encrypted_jsonb_param
jsonb_contains	encrypted	encrypted	contains_encrypted_encrypted
jsonb_contains	encrypted	encrypted_param	contains_encrypted_encrypted_param
jsonb_contains	jsonb_param	encrypted	contains_jsonb_param_encrypted
jsonb_contains	encrypted_param	encrypted	contains_encrypted_param_encrypted
jsonb_contained_by	encrypted	jsonb_param	contained_by_encrypted_jsonb_param
jsonb_contained_by	encrypted	encrypted	contained_by_encrypted_encrypted
jsonb_contained_by	encrypted	encrypted_param	contained_by_encrypted_encrypted_param
jsonb_contained_by	jsonb_param	encrypted	contained_by_jsonb_param_encrypted
jsonb_contained_by	encrypted_param	encrypted	contained_by_encrypted_param_encrypted

Plus 2 sanity tests and 2 helper validation tests.

Test plan

• Build succeeds
• All SQLx tests pass (14 containment + full suite)
• Lint passes (cargo fmt, clippy)

[coderdan]

Unfortunately, I don't think this implementation is correct. The problem is that containment operations on SteVec must only consider the selectors and terms and explicitly ignore the ciphertext values. The JsonIndexer in CipherStash client differentiates between a full SteVec and an SteQueryVec (just selectors and terms) for this reason.

Example

Let's say you have the below SteVec record in your table (as a cipher cell):

{
  "sv": [
    {"s":"a","b3":"1234","c":"aaa"},
    {"s":"a","b3":"1234","c":"bbb"}
  ]
}

Now, when you generate a query, if the query is also an (SteVec and not an SteQueryVec) then the values will never match. This is because ciphertexts are fully randomized and the same message encrypted twice will result in different values.

Say you have a query like (note that the c field is different):

{
  "sv": [
    {"s":"a","b3":"1234","c":"ccc"}
  ]
}

Then this query will not match:

select '[{"s":"a","b3":"1234","c":"aaa"}, {"s":"a","b3":"1234","c":"bbb"}]'::jsonb @> '[{"s":"a","b3":"1234","c":"ccc"}]'::jsonb;

However, if the query term is an SteQueryVec (i.e. no c field), then the following will work correctly:

select '[{"s":"a","b3":"1234","c":"aaa"}, {"s":"a","b3":"1234","c":"bbb"}]'::jsonb @> '[{"s":"a","b3":"1234"}]'::jsonb;

I think the reason the tests are passing in this PR is because the query terms are being taken from a value that was already inserted into the test table so the ciphertext will be the same. Its an artificial scenario because in practice the generated ciphertext will always be random.

[coderdan]

There's a problem in the implementation that we need to resolve. See longer comment.

[coderdan]

Related: it took me a moment to grok what was going on. It might be helpful to use a similar naming convention to the JsonIndexer? For example, instead of jsonb_array, perhaps we could call it ste_vec_entries?

[tobyhede]

@coderdan Was already working on the fix.
jsonb_array is the user facing name, ste_vec is an internal implementation detail.

[coderdan]

This might be better to generate a fresh ste_vec each time to increase confidence that even with randomized ciphertexts, the test still passes every time.

[coderdan]

Discussed with @tobyhede that this will happen in a follow-up PR once cipherstash-client is integrated into the tests.