Skip to content

Generate the value-type extended hashes (span / spanset / set) - #227

Open
estebanzimanyi wants to merge 3 commits into
mainfrom
feat/duck-hash-extended-valuetypes
Open

Generate the value-type extended hashes (span / spanset / set)#227
estebanzimanyi wants to merge 3 commits into
mainfrom
feat/duck-hash-extended-valuetypes

Conversation

@estebanzimanyi

Copy link
Copy Markdown
Member

Extends the seeded 64-bit hash to the value containers whose plain hash already generates: span_hash_extended / spanset_hash_extended / set_hash_extended — as hash_extended(<span|set>, UBIGINT) and spanset_hash_extended(spanset, UBIGINT), all returning UBIGINT (the native unsigned type, matching the temporal case).

  • Generator: adds a (container, by-value scalar) -> by-value scalar shape (bsc) to shape_span and shape_set, mirroring the existing unary u_scalar hash, plus the matching registration arms so the seed registers as its scalar type (UBIGINT) rather than a second container operand.
  • test/sql/temporal_hash.test: adds span/spanset/set extended-hash coverage (UBIGINT values across the full unsigned range).

The box hashes (tbox/stbox) and cbuffer are a separate gap — their plain hash does not generate yet either, so their extended form is out of scope here.

nhungoc1508 and others added 3 commits July 22, 2026 21:40
…ical

Regenerates the generated UDF surface from MobilityDB master (which brings in
the generic temporal_hash surface). The MEOS-API catalog now renders the uint32
canonical type as `unsigned int` (it was `uint32_t`); key the scalar type maps
on it so the *_hash functions keep registering instead of being dropped.

uint32 hashes map to DuckDB's native `UINTEGER`, not a signed `INTEGER` — a hash
>= 2**31 is out of range for INT32 and DuckDB range-checks the cast rather than
bit-reinterpreting the way PostgreSQL/C do; DuckDB has real unsigned SQL types,
so `UINTEGER` is the faithful representation.
Generates the extended (64-bit, seeded) hash `temporal_hash_extended(<ttype>,
UBIGINT)` for every temporal family, inherited through Temporal<T> — the Duck
side of the MEOS temporal_hash_extended surface.

The uint64 hash and its seed use DuckDB's native `UBIGINT`, not a signed BIGINT:
a MEOS hash fills the full unsigned range (e.g. temporal_hash_extended(tint
'1@2000-01-01', 0) = 11445401048662056440, which is > 2**63 and does not fit in
a signed BIGINT), and DuckDB range-checks the cast rather than bit-reinterpreting
the way PostgreSQL/C do.

Generator: key uint64_t to UBIGINT in the scalar arg/return maps (SCALAR,
SCALAR_ARG, SCALAR_RET_CPP), and check the Tcell cell-id branch before the
generic scalar branch in ret_type and shape_emittable so a uint64 cell id keeps
its cell type instead of collapsing to UBIGINT.
Extends the seeded 64-bit hash to the value containers whose plain hash already
generates: span_hash_extended / spanset_hash_extended / set_hash_extended, as
`hash_extended(<span|set>, UBIGINT)` and `spanset_hash_extended(spanset, UBIGINT)`,
all returning UBIGINT (the native unsigned type, per the temporal case).

Generator: add a (container, by-value scalar) -> by-value scalar shape ("bsc")
to shape_span and shape_set, mirroring the existing unary u_scalar hash, plus
the matching registration arms so the seed registers as its scalar type
(UBIGINT) rather than a second container operand.

(The box hashes tbox/stbox and cbuffer are a separate gap — their PLAIN hash
does not generate yet either, so their extended form is out of scope here.)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants