You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
EQL v3: make incorrect JSON functional indexes discoverable #980
For encrypted JSON containment, the indexable column expression is eql_v3.to_ste_vec_query(column)::jsonb. Calling eql_v3.ste_vec(column) is
also legal and produces an indexable type, so PostgreSQL accepts a GIN index on
it even though containment queries can never use that index.
The repository now documents the correct per-domain index recipes, but the SQL
function that creates the trap still gives no local indication that it is an
element accessor rather than an index-term extractor.
Acceptance criteria
COMMENT ON FUNCTION eql_v3.ste_vec(jsonb) identifies it as an element
accessor, warns that it is not the containment index expression, and points
to eql_v3.to_ste_vec_query(column)::jsonb.
The generated SQL bundle preserves that comment.
Index guidance and an EXPLAIN-backed regression test continue to use the exact
expression that the containment operator inlines to.
Historical provenance: cipherstash/encrypt-query-language#417. That repository
is archived; this Stack issue is the canonical location for remaining work.
Won't fix. This is EQL v3 behaviour, and v3 will not be changed further. The fix is in EQL v4's json_tree family (#1288, #1325, #1329, #1363), which does not reuse the v3 SteVec design.
Activity
coderdan commentedon Oct 25, 2026
Won't fix. This is EQL v3 behaviour, and v3 will not be changed further. The fix is in EQL v4's
json_treefamily (#1288, #1325, #1329, #1363), which does not reuse the v3 SteVec design.https://claude.ai/code/session_01N7bCqa3ZVJMcEE99RzVqEu