Skip to content

Conversation

@lukekim
Copy link
Collaborator

@lukekim lukekim commented Nov 25, 2025

No description provided.

* Upgrade rusqlite to v0.37 & tokio-rusqlite to v0.7

* v0.37 updates
SQLite does not natively support DECIMAL types - it stores them as REAL
(float64). Additionally, sea-query 0.32.x panics with 'assertion failed:
precision <= 16' when generating SQLite DDL with decimal precision > 16.

This change maps Decimal128 and Decimal256 types directly to Double in
build_sqlite(), which:
1. Avoids the sea-query panic for high-precision decimals
2. Matches SQLite's actual storage behavior (REAL/float64)
3. Is consistent with how decimals are decoded (as Float64) when reading
sea-query 0.32.x panics with 'assertion failed: precision <= 16' when
generating SQLite DDL for decimal types with precision > 16. Since SQLite
stores decimals as REAL (float64) anyway, map Decimal128 and Decimal256
types to ColumnType::Double before generating the DDL.

This fixes crashes when accelerating PostgreSQL tables with numeric columns
(default precision 38) to SQLite.

Includes test for high-precision decimal handling.
The prepared statement insert path was storing timestamps as integer
seconds, but SQLite's datetime functions expect TEXT in ISO 8601 format.
This caused round-trip failures where timestamps were read back as NULL.

Now timestamps are formatted as RFC3339 strings (or ISO 8601 without
timezone suffix for naive timestamps), matching how the legacy
InsertBuilder path formats them.

Also adds a helper function to parse timezone offset strings like
'+10:00' to seconds for proper timezone handling.

Fixes spiceai/spiceai#7629
@lukekim lukekim changed the title Lukim/sqlite decimal fix from spiceai SQLite timestamp fix Nov 26, 2025
@lukekim lukekim closed this Nov 26, 2025
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