[d-bytebase]

initValueFuncs resolved ParameterStatus("TimeZone") through time.LoadLocation for every timestamptz value scanned. Go reparses the zoneinfo file on each call for a named zone, so the cost landed per cell:

LoadLocation("Asia/Shanghai")   4341 ns/op   1376 B/op   10 allocs/op
LoadLocation("UTC")                2.7 ns/op      0 B/op    0 allocs/op   <- special-cased

Same query, 20k rows x 5 timestamptz, only the session zone differing:

TimeZone=UTC            100k cells   scan= 19ms   alloc=  2.3 MB
TimeZone=Asia/Shanghai  100k cells   scan=484ms   alloc=133.5 MB

The per-value lookup bought no accuracy for that. PostgreSQL reports a TimeZone change at command completion, after the rows, so every value in one result set resolves the same setting — measured with the patch in place:

SELECT set_config('TimeZone','Asia/Tokyo',false), '...'::timestamptz
  -> decoded UTC+0.00h, while ParameterStatus afterwards reads "Asia/Tokyo"

SELECT CASE WHEN i = 3 THEN set_config('TimeZone','Asia/Tokyo',false)
            ELSE current_setting('TimeZone') END, '...'::timestamptz
       FROM generate_series(1,5)
  -> all five rows decoded UTC, rows 3-5 reporting tz=Asia/Tokyo

So a caller can read the setting once per statement and apply the location itself for the same result, which also lets it fall back rather than fail a query whose TimeZone is a POSIX specification time.LoadLocation cannot parse (+08:00, EST5EDT,M3.2.0/2,M11.1.0/2) — something this code can only turn into a bare scan error that aborts the rest of the batch.

The ColumnTypePrecisionScale patch is untouched.

This reapplies #3, which #4 reverted so that an unrelated dependency bump carried no behavior change. The resulting tree is identical to the one reviewed there: git diff a6d159db HEAD is empty.

🤖 Generated with Claude Code