Re: Convert *GetDatum() and DatumGet*() macros to inline functions

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: Julien Rouhaud <rjuju123@gmail.com>, Aleksander Alekseev <aleksander@timescale.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2022-09-26T17:34:28Z
Lists: pgsql-hackers

Attachments

Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
>> Ok, it has problems with 32-bit platforms.  I can reproduce it locally. 
>> I'll need to take another look at this.  I have reverted the patch for now.

> I have tried to analyze these issues, but I'm quite stuck.  If anyone 
> else has any ideas, it would be helpful.

It looks to me like the problem is with the rewrite of Int64GetDatumFast
and Float8GetDatumFast:

+static inline Datum
+Int64GetDatumFast(int64 X)
+{
+#ifdef USE_FLOAT8_BYVAL
+	return Int64GetDatum(X);
+#else
+	return PointerGetDatum(&X);
+#endif
+}

In the by-ref code path, this is going to return the address of the
parameter local variable, which of course is broken as soon as the
function exits.  To test, I reverted the mods to those two macros,
and I got through check-world OK in a 32-bit VM.

I think we can do this while still having reasonable type-safety
by adding AssertVariableIsOfTypeMacro() checks to the macros.
An advantage of that solution is that we verify that the code
will be safe for a 32-bit build even in 64-bit builds.  (Of
course, it's just checking the variable's type not its lifespan,
but this is still a step forward.)

0001 attached is what you committed, 0002 is a proposed delta
to fix the Fast macros.

			regards, tom lane

Commits

  1. Convert *GetDatum() and DatumGet*() macros to inline functions

  2. Fix incorrect uses of Datum conversion macros