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
- 0001-original-commit.patch (text/x-diff) patch 0001
- 0002-fix-fast-macros.patch (text/x-diff) patch 0002
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
-
Convert *GetDatum() and DatumGet*() macros to inline functions
- c8b2ef05f481 16.0 landed
- 595836e99bf1 16.0 landed
-
Fix incorrect uses of Datum conversion macros
- 6bcda4a72123 16.0 landed