Horton

Re: Datum as struct

Peter Eisentraut <peter@eisentraut.org>

View thread View on postgr.es
From: Peter Eisentraut <peter@eisentraut.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2025-08-08T10:19:56Z
Lists: pgsql-hackers 
On 07.08.25 03:55, Tom Lane wrote:
> I wrote:
>> I think that on a 32-bit machine this would actually result in a
>> null-pointer core dump, since the 0.0 would be coerced to a zero
>> Datum value.  The line is not reached in our regression tests,
>> and given the lack of field complaints, it must be hard to reach
>> in normal use too.  Or 32-bit machines are deader than I thought.
> 
> On closer inspection, it's unreachable because bqarr_in won't
> accept an empty query, and there is no other function that will
> create query_int values.  So probably it's not worth the trouble
> to back-patch.

I ended up backpatching this, since it was easy enough and I didn't want 
to leave such patently broken code lie around.  And it will allow us to 
label the remaining cleanup patches as "harmless".  I'll go commit those 
to master next.

Commits

  1. Use consistent type for pgaio_io_get_id() result

  2. Mop-up for Datum conversion cleanups.

  3. Add missing Datum conversions

  4. Remove useless/superfluous Datum conversions

  5. Fix incorrect lack of Datum conversion in _int_matchsel()

  6. Improve tests of date_trunc() with infinity and unsupported units

  7. Fix incorrect Datum conversion in timestamptz_trunc_internal()

  8. Fix various hash function uses

  9. Fix mixups of FooGetDatum() vs. DatumGetFoo()