Arrow import ignores the file's declared Int/Float/FixedSizeBinary/Decimal parameters

[jdatcmd]

What is unchecked

imp_apply_field in src/columnar_arrow.c inspects exactly three Arrow type tags — Date,
Time and Timestamp — with default: break for everything else. So on import the file's
declared

• Int.bitWidth and Int.is_signed
• floating-point width
• FixedSizeBinary.byteWidth
• Decimal precision and scale

are never read. The stride and interpretation come from the target PostgreSQL column rather
than from the file. This is the same class of defect as #864/#865, which #870 fixed for the
temporal types only.

What is already safe, so this is not a memory-safety report

The import validates buffer lengths: "value buffer too small for the row count". Any case
where the file's carrier is narrower than the target — float16 into float8,
fixed_size_binary(8) into uuid, int32 into bigint — is refused as corrupt rather than
read out of bounds.

What survives that check, and is therefore silent

Cases where the carrier matches or exceeds the target:

file declares	column	what should happen
uint64	bigint	values >= 2^63 are read as negative
int64	int / smallint	stride is the target's, so values are read from the wrong offsets
decimal128(10,2)	numeric(20,4)	same 16-byte carrier, wrong scale — values off by powers of ten

Status of this report

Read from the code, not measured. I have verified the three-tag limit and the buffer-length
check by reading main; the three outcomes above follow from them but I have not run any of
them. Whoever picks this up should start by building the corpus files and making each one fail
before writing a fix — test/arrow_corpus.py already emits typed Arrow fixtures via pyarrow and
is the natural place to add them.

Prior art

#861 was written to cover exactly this, alongside a temporal policy that has since been decided
the other way (see the closing comment there, and #880). Its non-temporal arms are worth reading
before starting, but not rebasing: that branch predates #870 and its head had deleted its own
Int.is_signed check, so its uint64 into bigint arm was red on its own terms.

[jdatcmd]

Fixed in #883, merged as b7a44c4, shipped in v1.0-alpha3.

I filed this from code reading and refused to rank it until measured. Measured, all four cases were real and the wrong values were persisted:

file declares	column	in the file	was stored
uint64	bigint	9223372036854775813	−9223372036854775803
int64	int	1, 2, 3, 4	1, 0, 2, 0
decimal128(10,2)	numeric(20,4)	1.25	0.0125
fixed_size_binary(32)	uuid	32 bytes	the first 16

All refused now with 42804. imp_apply_field reads the file's declared Int.bitWidth/is_signed, float width, FixedSizeBinary.byteWidth and decimal precision/scale.

Scope is within a family. An int64 read into a timestamp as raw microseconds is long-standing accepted behaviour with its own control; the first attempt at this broke it.

Removal proof, per family, one .so per arm:

unmutated                        72 + 0
Int check removed                68 + 4    uint64/int64 return 00000
Float check removed              71 + 1
Decimal check removed            71 + 1
FixedSizeBinary check removed    71 + 1

The FSB arm exists because the first version had none and the check was dead: the obvious fixture (fsb(8)) is already refused by the buffer-length check, so it cannot distinguish the guard from its absence. The discriminating arm uses a wider carrier.

Note the 1,0,2,0: the release notes first said 0,0,1,2, which was that multiset sorted. The real signature is a value alternating with a zero — corrected in #886 before the tag moved.