Re: Datum as struct - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Datum as struct
Date
Msg-id 1482320.1754530382@sss.pgh.pa.us
Whole thread Raw
In response to Re: Datum as struct  (Peter Eisentraut <peter@eisentraut.org>)
Responses Re: Datum as struct
List pgsql-hackers
Peter Eisentraut <peter@eisentraut.org> writes:
>> On 05.08.25 20:06, Peter Eisentraut wrote:
>>> -                    PG_RETURN_TIMESTAMPTZ(timestamp);
>>> +                    return timestamp;

>> This one is an actual bug.

I took another look through this patch series and realized that this
bit from 0003 is also a live bug that should be back-patched, for
exactly the same reason as with the above:

diff --git a/contrib/intarray/_int_selfuncs.c b/contrib/intarray/_int_selfuncs.c
index 6c3b7ace146..9bf64486242 100644
--- a/contrib/intarray/_int_selfuncs.c
+++ b/contrib/intarray/_int_selfuncs.c
@@ -177,7 +177,7 @@ _int_matchsel(PG_FUNCTION_ARGS)
     if (query->size == 0)
     {
         ReleaseVariableStats(vardata);
-        return (Selectivity) 0.0;
+        PG_RETURN_FLOAT8(0.0);
     }

     /*

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.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Dead code with short varlenas in toast_save_datum()
Next
From: Thomas Munro
Date:
Subject: Re: [PATCH] OAuth: fix performance bug with stuck multiplexer events