Make typed reads statically compilable under juliac --trim

[quinnj]

Problem

juliac --trim=safe rejected typed queries. An application with a few hundred row structs hit 1,455 verifier errors, all in Postgres.jl:

• 1,443: typed fields that aren't timestamps or decimals were decoded by the column's OID decoder, which returns Any, so every field's StructUtils.make call was a runtime dispatch.
• 12: in protocol and parameter code.

Separately, reading a json/jsonb column (or any non-text column) into a String field threw MethodError: Cannot convert JSON.LazyValue{String} to String.

There was no failing test for the trim problem: the 1.0 release removed test/trim_compile_tests.jl.

Change

Typed reads (default PostgresStyle).

• Fields whose type Postgres.jl parses from text now decode from the column text by their declared type. That covers strings, symbols, enums, integers, floats, Bool, Char, Date, Time, DateTime, UUID, bytea, lazy JSON, timestamps, decimals, vectors of these, and each wrapped in Union{Nothing,…}/Union{Missing,…}. The source stays a String, so each read compiles to static calls.
• A String field receives any column's text.
• Conversions that worked before are kept:
  • Integer fields accept integral numeric text such as 12.00 and throw InexactError when out of range.
  • A Date field reads the UTC date of a timestamptz.
• A parser registered for the column still applies when its declared type fits the field.
• Custom styles keep the OID decoder, so their lift methods still receive decoded values. Other field types keep it too.

Other trim fixes.

• Protocol strings containing a NUL byte threw UndefVarError instead of PostgresInterfaceError. The check referred to Postgres.PostgresInterfaceError from inside API.
• writestartupmessage took an unused statement_timeout. With options passed as a String, the call no longer needs runtime dispatch.
• writemessages and tuple parameters to execute iterated heterogeneous tuples in a loop. Both now unroll; the parameter case reuses bind_tuple_params!.
• Date/DateTime parameters used string(x), whose Dates printing is not trim-safe. They now use a static formatter that produces the same text.

Restored trim test.

• test/trim_compile_tests.jl compiles test/postgres_trim_queries.jl with JuliaC and requires zero verifier errors. It then runs the executable against the test database under trust auth.
• The workload covers nullable strings and timestamps, numerics into Float64/Int, enums, arrays, and jsonb into String. It also covers prepared statements, transactions, and parameters of each bound type.
• JuliaC needs Julia 1.12, so it lives in test/trim/Project.toml, as in JSON.jl.
• Released Julia's Base64 pipes and Dates.CompoundPeriod constructor are not trim-safe; SASLAuth's SCRAM exchange and interval decoding reach them. Errors raised inside those stdlib files are reported but not counted. The compile uses --trim=unsafe-warn so the executable still builds.

Version bumped to 2.3.0 for the behavior changes below.

Behavior changes (default style, typed fields)

• An Int/Float field over a bool column now errors; it previously read 1/0.
• A registered parser whose declared type doesn't fit the field is no longer applied and then converted. The field parses the column text instead.

Verification

• Full test suite locally, including the live-database tests and the restored trim test: 0 Postgres.jl verifier errors (30 stdlib-gap errors reported separately), and the compiled executable ran its workload successfully. The only other error was the Kerberos fixture, whose Docker image failed to install packages (Could not resolve deb.debian.org); it passed on the previous run.
• In a downstream application (about 1,400 typed queries) built with juliac --trim=safe and stdlib patches, verifier errors went from 1,472 to 17. The remaining 17 are pre-existing and in the application's own code. Its 8,751-test integration suite passes.

🤖 Generated with Claude Code

[PingoLee]

Thanks for this. I compared typed reads between main and this branch with a matrix: 38 field types (each scalar, Union{Nothing/Missing,…}, a few unions and vectors) × 87 column values (limits, NaN/Infinity, exponent-form floats, long numerics, BC and infinity dates, timestamptz with odd offsets, arrays with NULLs…) × 7 session settings (TimeZone, IntervalStyle, bytea_output, extra_float_digits), about 23,000 reads per side on PostgreSQL 18 and Julia 1.13. Everything under "Behavior changes" reproduced as described, and the Date/DateTime parameter formatter produced the same text as string(x) in every case, including 5-digit and negative years.

Leaving aside pairings that already produced nonsense on main (e.g. an int4 column into a Vector{Int64} field), three regressions aren't in that list:

1. An Int field over a float4/float8 column with a value of 1e15 or more. PostgreSQL prints these in exponent form (SELECT 1e15::float8 returns 1e+15), so pg_parse_integer falls through to Parsers.parse(Int64, "1e+15") and throws ArgumentError. On main the field reads 1000000000000000.

2. Union field types. _text_field(Union{Int64, Float64}) is true, because the union is a subtype of TextField, but nothing lifts text into the union. A Union{Int64, Float64} field over a float8 column now throws MethodError (main: the Float64), and a Union{Int64, String} field over an int8 column now gets a String (main: the Int64).

3. A Time field over a timestamp/timestamptz column. On main it reads the (UTC) time of day, e.g. Time(23, 59, 59, 999, 999); now pg_parse_time throws ArgumentError. It's the counterpart of the Date-from-timestamptz conversion this PR keeps.

A possible fix for all three, which I tried on this branch. With it, every one of these cases reads as on main across all 7 settings, and the full suite passes locally (Julia 1.13, Linux), including the restored trim test: 0 Postgres.jl verifier errors, and the compiled executable runs its workload against the database.

Patch

--- a/src/api/types.jl
+++ b/src/api/types.jl
@@ -409,6 +409,8 @@ end
 
 # timestamp(tz) column into a Date field: the UTC date, as for DateTime fields
 pg_parse_date_any(s::AbstractString)::Date = occursin(':', s) ? Date(pg_parse_datetime_any(s)) : pg_parse_date(s)
+# timestamp(tz) column into a Time field: the UTC time of day
+pg_parse_time_any(s::AbstractString)::Time = occursin(' ', s) ? convert(Time, pg_parse_timestamp(s)) : pg_parse_time(s)
 
 # Integer fields also read integral numeric text such as "12.00" (numeric
 # columns, or SUM over one). Out-of-range values throw InexactError, as when
@@ -423,7 +425,13 @@ function pg_parse_integer(::Type{T}, s::AbstractString) where {T <: Integer}
             wide = Parsers.tryparse(Int128, SubString(s, 1, dot - 1))
         end
     end
-    wide === nothing && return Parsers.parse(T, s)
+    if wide === nothing
+        # float4/float8 columns print large values in exponent form ("1e+16");
+        # numeric never does, so this conversion is exact
+        f = (occursin('e', s) || occursin('E', s)) ? Parsers.tryparse(Float64, s) : nothing
+        f === nothing && return Parsers.parse(T, s)
+        return convert(T, f)
+    end
     return convert(T, wide)
 end
 
@@ -1003,7 +1011,7 @@ const TextField = Union{String, Symbol, Bool, Char, Int8, Int16, Int32, Int64, C
     Date, Time, DateTime, UUID, Vector{UInt8}, JSONType, Vector{String}, Vector{Int16}, Vector{Int32},
     Vector{Int64}, Vector{Float32}, Vector{Float64}, Vector{Bool}, Vector{Date}, Vector{Time},
     Vector{DateTime}, Vector{UUID}, Vector{Char}}
-_text_field(::Type{S}) where {S} = S !== Union{} && (S <: Union{TextField, Enum} || S === IntervalType || _wire_field(S))
+_text_field(::Type{S}) where {S} = S === IntervalType || (S !== Union{} && !(S isa Union) && (S <: Union{TextField, Enum} || _wire_field(S)))
 
 function _field_source(::PostgresStyle, ::Type{T}, v::FieldValue) where {T}
     S = Base.nonnothingtype(Base.nonmissingtype(T))
@@ -1056,7 +1064,7 @@ StructUtils.lift(::AbstractPostgresStyle, ::Type{Cuint}, s::String) = pg_parse_i
 StructUtils.lift(::AbstractPostgresStyle, ::Type{Float32}, s::String) = Parsers.parse(Float32, s), nothing
 StructUtils.lift(::AbstractPostgresStyle, ::Type{Float64}, s::String) = Parsers.parse(Float64, s), nothing
 StructUtils.lift(::AbstractPostgresStyle, ::Type{Date}, s::String) = pg_parse_date_any(s), nothing
-StructUtils.lift(::AbstractPostgresStyle, ::Type{Time}, s::String) = pg_parse_time(s), nothing
+StructUtils.lift(::AbstractPostgresStyle, ::Type{Time}, s::String) = pg_parse_time_any(s), nothing
 StructUtils.lift(::AbstractPostgresStyle, ::Type{DateTime}, s::String) = pg_parse_datetime_any(s), nothing
 StructUtils.lift(::AbstractPostgresStyle, ::Type{UUID}, s::String) = UUID(s), nothing
 StructUtils.lift(::AbstractPostgresStyle, ::Type{IntervalType}, s::String) = parse_interval(s), nothing
--- a/src/array_parsing.jl
+++ b/src/array_parsing.jl
@@ -4,7 +4,7 @@ using Parsers, Dates, UUIDs
 import Durations, DataDecimals
 import ..parse_decimal
 import ..pg_parse_timestamp
-import ..pg_parse_date, ..pg_parse_date_any, ..pg_parse_time, ..pg_parse_datetime_any, ..pg_parse_char, ..pg_parse_integer
+import ..pg_parse_date, ..pg_parse_date_any, ..pg_parse_time, ..pg_parse_time_any, ..pg_parse_datetime_any, ..pg_parse_char, ..pg_parse_integer
 
 const BRACKET_OPEN = UInt8('[')
 const BRACKET_CLOSE = UInt8(']')
@@ -94,7 +94,7 @@ function parse_scalar(token::String, inner_type::Type{T}, quoted::Bool) where {T
     inner_type === Float32 && return Parsers.parse(Float32, token)
     inner_type === Float64 && return Parsers.parse(Float64, token)
     inner_type === Date && return pg_parse_date_any(token)
-    inner_type === Time && return pg_parse_time(token)
+    inner_type === Time && return pg_parse_time_any(token)
     inner_type <: Durations.Timestamp && return pg_parse_timestamp(token, inner_type)
     inner_type === DateTime && return pg_parse_datetime_any(token)
     inner_type === UUID && return UUID(token)

Smaller differences, probably fine either way:

• An Int field over non-integral text (3.5::float8, 12.50::numeric) now throws ArgumentError from Parsers instead of InexactError.
• A Float64 field over a float4 column now reads the printed value, 0.1, instead of the widened Float32, 0.10000000149011612. That matches the text the server sends, but it changes the value silently.
• A Union{Nothing, String} field over a json 'null' now reads "null" instead of nothing. The column isn't SQL NULL, so this looks like a fix.

---

AI use: the edge-case matrix, the suggested fix and the test runs were done with Claude Code (Claude Opus 5.5). I reviewed the results and this comment before posting.