Re: Convert *GetDatum() and DatumGet*() macros to inline functions - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Convert *GetDatum() and DatumGet*() macros to inline functions
Date
Msg-id 812568f2-ff1d-ebd9-aee6-e00d8f2e0fb6@enterprisedb.com
Whole thread Raw
In response to Re: Convert *GetDatum() and DatumGet*() macros to inline functions  (Aleksander Alekseev <aleksander@timescale.com>)
Responses Re: Convert *GetDatum() and DatumGet*() macros to inline functions  (Aleksander Alekseev <aleksander@timescale.com>)
List pgsql-hackers
On 30.08.22 20:15, Aleksander Alekseev wrote:
>> Here is v3 with silenced compiler warnings.
> 
> Some more warnings were reported by cfbot, so here is v4. Apologies
> for the noise.

Looking at these warnings you are fixing, I think there is a small 
problem we need to address.

I have defined PointerGetDatum() with a const argument:

PointerGetDatum(const void *X)

This is because in some places the thing that is being passed into that 
is itself defined as const, so this is the clean way to avoid warnings 
about dropping constness.

However, some support functions for gist and text search pass back 
return values via pointer arguments, like

                 DirectFunctionCall3(g_int_same,
                                     entry->key,
                                     PointerGetDatum(query),
                                     PointerGetDatum(&retval));

The compiler you are using apparently thinks that passing &retval to a 
const pointer argument cannot change retval, which seems quite 
reasonable.  But that isn't actually what's happening here, so we're 
lying a bit.

(Which compiler is that, by the way?)

I think to resolve that we could either

1. Not define PointerGetDatum() with a const argument, and just sprinkle 
in a few unconstify calls where necessary.

2. Maybe add a NonconstPointerGetDatum() for those few cases where 
pointer arguments are used for return values.

3. Go with your patch and just fix up the warnings about uninitialized 
variables.  But that seems the least principled to me.



pgsql-hackers by date:

Previous
From: "Drouvot, Bertrand"
Date:
Subject: Re: Patch to address creation of PgStat* contexts with null parent context
Next
From: Justin Pryzby
Date:
Subject: Re: Different compression methods for FPI