Numbers

Six numeric types share one identical query surface: int2, int4, int8, float4, float8, and numeric. These are the columns you filter by range, sort, and take a MIN / MAX over — salaries, totals, rates, quantities.

Date and time columns have the same capabilities but their own semantics — see Dates & times. There is no free-text matching for numeric types — _match and _search are text-only variants.

Variants

Each numeric type generates the same jsonb-backed domain variants. The generic form:

<T> is the encrypted type name from the table below, so public.eql_v3_<T>_ord is public.eql_v3_bigint_ord for int8.

And every concrete domain this page covers:

Declare only the capability you query on — each capability stores extra searchable material with defined leakage (see Searchable encryption), and the variant model itself is covered in Core concepts.

Example

A payroll table mixing the variants by how each column is queried:

CREATE TABLE employees (
    id         bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    salary     public.eql_v3_bigint_ord,       -- range queries, ORDER BY, MIN/MAX
    tax_rate   public.eql_v3_numeric_eq,     -- exact lookup only
    net_worth  public.eql_v3_numeric         -- store and decrypt only, never queried
);

SEM specifiers

All six types take the same mechanism specifiers on their orderable variant (the concept is defined in Core concepts):

<T>_ord and <T>_ord_ope are byte-identical today. Pin _ord_ope when you want a column's mechanism frozen against a future change of the default.

Payload

A value for an _ord column carries the shared envelope keys (v, i, c — see Core concepts) plus the op ordering term. Here is a payload for the public.eql_v3_bigint_ord salary column:

{
  "v": 3,
  "i": { "t": "employees", "c": "salary" },
  "c": "mBbKmsMM%bK#QQOx1yLDBHyD...",
  "op": "5f2b1a9e4c07d38b6ea15c92..."
}

• op is the only index term. It is a hex-encoded CLLW OPE ciphertext, which Postgres sorts by native bytea comparison. An _ord payload carries no hm, because ordering over a numeric scalar is equality-lossless: = and <> resolve against the same term. Only _eq payloads carry hm (a single hex HMAC-SHA-256 string) instead.
• An _ord_ore payload carries ob in place of op: an array of block-ORE ciphertexts, 8 blocks for the int types and 14 for numeric.

Operators

Blocked operator cells raise an operator … is not supported exception — they never silently return wrong rows. ORDER BY is the one blocked cell that doesn't raise: it isn't an operator, so sorting a variant without an ordering term runs — but the order is meaningless (see Sorting). Operands must be typed ($1::public.eql_v3_bigint_ord), or PostgreSQL resolves the native jsonb operator instead of the encrypted one. Both rules are covered in Core concepts.

Functions

Every operator has a function form, for managed platforms that disallow custom operators — same typed arguments, identical resolution. Each lists the encrypted domains it applies to; the MIN / MAX aggregates only exist as functions.

eql_v3.eq(a, b)

SELECT * FROM payments
WHERE eql_v3.eq(amount, $1::public.eql_v3_bigint_eq);

eql_v3.neq(a, b)

SELECT * FROM payments
WHERE eql_v3.neq(amount, $1::public.eql_v3_bigint_eq);

eql_v3.lt / lte / gt / gte

-- a range uses two of the four
SELECT * FROM payments
WHERE eql_v3.gte(amount, $1::public.eql_v3_bigint_ord)
  AND eql_v3.lt(amount, $2::public.eql_v3_bigint_ord);

eql_v3.min(col)

-- compares ordering terms; result decrypts client-side
SELECT eql_v3.min(amount) FROM payments;

eql_v3.max(col)

SELECT eql_v3.max(amount) FROM payments;

SUM, AVG, and other arithmetic aggregates are not supported on encrypted columns — they would require homomorphic encryption. MIN / MAX work because they only need comparison; for sums and averages, decrypt at the application boundary and aggregate client-side.

Where to next