Skip to content

postgres: emit full leading-zero groups when binary-decoding sub-1e-8 NUMERIC - #31211

Merged
dylan-conway merged 1 commit into
mainfrom
ali/pg-numeric-binary-leading-zeros
May 27, 2026
Merged

postgres: emit full leading-zero groups when binary-decoding sub-1e-8 NUMERIC#31211
dylan-conway merged 1 commit into
mainfrom
ali/pg-numeric-binary-leading-zeros

postgres: emit full leading-zero groups when binary-decoding sub-1e-8…

bf729d3
Select commit
Loading
Failed to load commit list.
Claude / Claude Code Review completed May 22, 2026 in 17m 25s

Code review found 1 potential issue

Found 1 candidates, confirmed 1. See review comments for details.

Details

Severity Count
🔴 Important 0
🟡 Nit 0
🟣 Pre-existing 1
Severity File:Line Issue
🟣 Pre-existing src/sql_jsc/postgres/DataCell.rs:1357-1360 ndigits==0 early return drops dscale (pre-existing get_str_from_var divergence)

Annotations

Check notice on line 1360 in src/sql_jsc/postgres/DataCell.rs

See this annotation in the file changed.

@claude claude / Claude Code Review

ndigits==0 early return drops dscale (pre-existing get_str_from_var divergence)

Pre-existing nit, not introduced here: the `if ndigits == 0 { return "0" }` early return a few lines above this hunk ignores `dscale`, so a binary-encoded zero with display scale (e.g. `0::numeric(10,2)`, sent as `{ndigits=0, weight=0, sign=0, dscale=2}`) decodes as `"0"` while text protocol and Postgres' `get_str_from_var` both yield `"0.00"`. It's the one remaining `get_str_from_var` divergence in this function and the new test's `"0"` case uses `dscale=0` so doesn't cover it; note that simply