feat: Additional uint datatype support for the SQL interface

[alexander-beedie]

Finally got to grips with destructuring a nested vec ("hello as_slice"😜) so was able to cleanly register some custom datatypes with the SQL parser.

Patch notes

• PostgreSQL supports the following integer types int2,int4,int8 (for which we also allow the smallint, integer and bigint aliases). Unfortunately it does not offer unsigned ints, and the parser doesn't offer them (directly) either. We also allow tinyint for 1 byte ints.

• There is an extension called pguint¹ (maintained by one of the PostgreSQL core developers) that adds uint1,uint2,uint4, and uint8 types, as well as int1.

• This PR adds support for these additional integer types by registering them via the parser's SQLDataType::Custom extension point.

• Also contains a fix for "CAST", making it strict by default; previously we might silently eat invalid/overflowing casts and return null values, which is not desirable.

• Sorted type parsing code into blocks of related dtypes (vs lexical order) for clarity.

Example

import polars as pl

df = pl.DataFrame({"n": [1,2,3]})

df.sql("""
  SELECT 
    n::int1   AS ni8,   -- new
    n::int2   AS ni16,
    n::int4   AS ni32,
    n::int8   AS ni64,
    n::float4 AS nf32,
    n::float8 AS nf64,
    n::uint1  AS nu8,   -- new
    n::uint2  AS nu16,  -- new
    n::uint4  AS nu32,  -- new
    n::uint8  AS nu64,  -- new
  FROM self
""")

# shape: (3, 10)
# ┌─────┬──────┬──────┬──────┬──────┬──────┬─────┬──────┬──────┬──────┐
# │ ni8 ┆ ni16 ┆ ni32 ┆ ni64 ┆ nf32 ┆ nf64 ┆ nu8 ┆ nu16 ┆ nu32 ┆ nu64 │
# │ --- ┆ ---  ┆ ---  ┆ ---  ┆ ---  ┆ ---  ┆ --- ┆ ---  ┆ ---  ┆ ---  │
# │ i8  ┆ i16  ┆ i32  ┆ i64  ┆ f32  ┆ f64  ┆ u8  ┆ u16  ┆ u32  ┆ u64  │
# ╞═════╪══════╪══════╪══════╪══════╪══════╪═════╪══════╪══════╪══════╡
# │ 1   ┆ 1    ┆ 1    ┆ 1    ┆ 1.0  ┆ 1.0  ┆ 1   ┆ 1    ┆ 1    ┆ 1    │
# │ 2   ┆ 2    ┆ 2    ┆ 2    ┆ 2.0  ┆ 2.0  ┆ 2   ┆ 2    ┆ 2    ┆ 2    │
# │ 3   ┆ 3    ┆ 3    ┆ 3    ┆ 3.0  ┆ 3.0  ┆ 3   ┆ 3    ┆ 3    ┆ 3    │
# └─────┴──────┴──────┴──────┴──────┴──────┴─────┴──────┴──────┴──────┘

(Note that PostgreSQL defines its datatype sizes in bytes, not bits).

Footnotes

1. https://github.com/petere/pguint ↩

[codecov]

Codecov Report

Attention: Patch coverage is 82.35294% with 6 lines in your changes are missing coverage. Please review.

Project coverage is 80.95%. Comparing base (31eaabe) to head (735adfc).
Report is 2 commits behind head on main.

Files	Patch %	Lines
crates/polars-sql/src/sql_expr.rs	82.35%	6 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #15993      +/-   ##
==========================================
+ Coverage   80.89%   80.95%   +0.05%     
==========================================
  Files        1384     1384              
  Lines      178047   178110      +63     
  Branches     3043     3043              
==========================================
+ Hits       144035   144192     +157     
+ Misses      33528    33436      -92     
+ Partials      484      482       -2     

Flag	Coverage Δ
python	74.44% <79.41%> (+0.05%)	⬆️
rust	78.09% <82.35%> (+0.05%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[mcrumiller]

In postgres smallint is an alias for int2, int for 4-bytes, and bigint for 8-bytes. I've seen tinyint in MSSQL for 1-byte ints, but not in postgres. Could this cause confusion?

https://www.postgresql.org/docs/8.1/datatype.html#DATATYPE-INT.

[alexander-beedie]

In postgres smallint is an alias for int2, int for 4-bytes, and bigint for 8-bytes. I've seen tinyint in MSSQL for 1-byte ints, but not in postgres. Could this cause confusion?

Ahh, the only thing causing confusion there was me committing an "off by one" error when aligning the int1/2/4/8 types with their tiny/small/big/etc counterparts. Fixed it in the description - the actual code/parsing behaves entirely as expected 😄