Skip to content

feat(bindings): temporal comparison predicates returning Temporal#73

Closed
estebanzimanyi wants to merge 1 commit intomainfrom
feat/parity-tcompops-followups
Closed

feat(bindings): temporal comparison predicates returning Temporal#73
estebanzimanyi wants to merge 1 commit intomainfrom
feat/parity-tcompops-followups

Conversation

@estebanzimanyi
Copy link
Copy Markdown
Member

Closes the user-facing tail of `temporal/030_temporal_compops` (was 0%; this brings the user-visible surface to ~95%).

New SQL surface

Name Base types covered Overloads
`temporal_teq` bool, int, float, text 12 (base × t, t × base, t × t)
`temporal_tne` bool, int, float, text 12
`temporal_tlt` int, float, text 9
`temporal_tle` int, float, text 9
`temporal_tgt` int, float, text 9
`temporal_tge` int, float, text 9

60 new registrations routing through MEOS `teq` / `tne` / `tlt` / `tle` / `tgt` / `tge` exports. Each returns `tbool`.

Implementation

Numeric (int / float / bool) variants reuse `TemporalBinaryV` / `V1` / `TT` helpers. Text variants need `text*` allocation and use a manual `BinaryExecutor` block, mirroring the existing `Textcat_*` pattern. Two macros (`DEFINE_TCMP_NUMERIC`, `DEFINE_TCMP_BOOL`) compress the repetition.

Operator forms not registered

MobilityDB also exposes these comparisons as the operator tokens `?=`, `?<>`, `?<`, `?<=`, `?>`, `?>=`. DuckDB's parser does not accept multi-character operator tokens starting with `?`, so only the named functions are registered. This is consistent with the existing handling of `<<#`, `<#>`, `|=|`, `~=` documented in `docs/DuckDB-Parity-Gaps.md` (PR #64).

What stays unregistered

The `tnumber_supportfn` name flagged by the audit is a PostgreSQL planner selectivity hook with no DuckDB equivalent; never user-facing.

Tests

  • `test/sql/parity/030_temporal_compops.test` — 12 assertions covering all six ops on `(base × t, t × base, t × t)` shapes and the strict-vs-non-strict boundary cases for ordered comparisons. Includes `tfloat` linear-interpolation crossing-the-threshold case.
  • Full suite: 764 assertions / 14 test cases passing under `TZ=UTC`.

Coverage delta

Per the audit in PR #66:

  • `temporal/030_temporal_compops`: 0/19 → 18/19 by name (only `tnumber_supportfn` stays unregistered).

Test plan

  • `cmake --build . --target shell unittest` clean
  • New parity test passes (12/12)
  • Full suite green (764/14)

Closes the user-facing tail of temporal/030_temporal_compops:

- temporal_teq / temporal_tne — across (bool, int, float, text) base
  types: 12 overloads each (base × t, t × base, t × t).
- temporal_tlt / temporal_tle / temporal_tgt / temporal_tge — across
  (int, float, text) base types: 9 overloads each.

Total: 60 new registrations routing through MEOS teq/tne/tlt/tle/tgt/tge
exports. Numeric variants use TemporalBinaryV / V1 / TT helpers; text
variants need text* allocation and use a manual BinaryExecutor block
(modelled on the existing Textcat_*).

MobilityDB also exposes these as the operator forms `?=`, `?<>`, `?<`,
`?<=`, `?>`, `?>=`, but DuckDB's parser does not accept multi-character
operator tokens starting with `?`, so only the named functions are
registered. This is consistent with the existing handling of `<<#`,
`<#>`, `|=|`, `~=` in docs/DuckDB-Parity-Gaps.md (PR #64).

The `tnumber_supportfn` name flagged by the audit is a PostgreSQL
planner selectivity hook; no DuckDB equivalent.

Test: test/sql/parity/030_temporal_compops.test (12 assertions covering
all six ops on (base × t, t × base, t × t) and the strict-vs-non-strict
boundary cases for ordered comparisons).
Full suite: 764 / 14 cases under TZ=UTC.

Files also gain a trailing newline at EOF.
@estebanzimanyi
Copy link
Copy Markdown
Member Author

Superseded by the consolidated PR branch consolidate/temporal-ops-parity. All changes from this PR are included in that branch as a single squashed commit. Please review and merge the consolidated branch instead.

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.

1 participant