Feedback-ID: ie0a040ee:Fastmail
Message-ID: <4c1f88d7-5102-45b3-94e3-86d7e4b46b0a@eisentraut.org>
Date: Thu, 16 Apr 2026 10:45:55 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Reduce build times of pg_trgm GIN indexes
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, David Geier <geidav.pg@gmail.com>,
 Matthias van de Meent <boekewurm+postgres@gmail.com>,
 pgsql-hackers <pgsql-hackers@postgresql.org>
References: <5d366878-2007-4d31-861e-19294b7a583b@gmail.com>
 <9ac3931a-180e-4283-a7a8-05eb66099206@iki.fi>
 <e5dd01c6-c469-405d-aea2-feca0b2dc34d@gmail.com>
 <2e11134f-02c3-43da-8c39-fb520a1a251d@iki.fi>
 <66620ec7-0f81-4813-9cf1-b901a56efcc3@gmail.com>
 <CAEze2WiUL9idZBbuUN+MuWqr6DcPr_-C91E9MTx=H62Xx5fHaQ@mail.gmail.com>
 <ef8782c9-68b7-4915-9f79-497765a8e205@gmail.com>
 <a90ebbbd-0d77-49c7-b222-3dbffa4e3b14@gmail.com>
 <2a76b5ef-4b12-4023-93a1-eed6e64968f3@gmail.com>
 <6439c655-e281-409d-b884-6586750d5820@iki.fi>
 <342012.1776017102@sss.pgh.pa.us>
 <8f3fab0e-02e1-4948-9683-224fe54e30ae@iki.fi>
 <77cc23dd-ac53-4bb9-9e90-0019c9ff58df@gmail.com>
 <195097d6-64cd-4adb-b8a3-1d86ae31c411@iki.fi>
 <aa908216-6ed6-4d19-b63c-a13441aeae4c@eisentraut.org>
 <2197023.1776288324@sss.pgh.pa.us>
Content-Language: en-US
From: Peter Eisentraut <peter@eisentraut.org>
In-Reply-To: <2197023.1776288324@sss.pgh.pa.us>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/4c1f88d7-5102-45b3-94e3-86d7e4b46b0a%40eisentraut.org>
Precedence: bulk

On 15.04.26 23:25, Tom Lane wrote:
> Peter Eisentraut <peter@eisentraut.org> writes:
>> On 15.04.26 13:06, Heikki Linnakangas wrote:
>>> This was briefly discussed when PointerGetDatum() was changed from a
>>> macro to a static inline function [1]. On that email, Peter pointed out
>>> that the compiler was doing the same deduction that Coverity did now,
>>> i.e. that if you pass the Datum returned by PointerGetDatum(&foo) to a
>>> function, it cannot change *foo. I'm surprised we dismissed that worry
>>> so quickly. If the compiler optimizes based on that assumption, you can
>>> get incorrect code.
> 
>> I don't think this is in evidence.  AFAICT, it's just Coverity that is
>> complaining here, which is its right, but the code is not incorrect.
> 
> Are you sure?  This seems like the sort of thing that will bite us on
> the rear sometime in the future, as the compiler geeks put in more and
> more aggressive optimizations.
> 
> I think we should at least test the theory that changing
> PointerGetDatum to remove the const cast would silence Coverity's
> complaint.  If it does not then we're attributing too much
> intelligence to Coverity.  But if it does, then we've correctly
> identified why it's complaining, and we should take seriously the
> idea that they aren't the only ones making this sort of deduction
> (or won't be for long).

I think it's quite clear to me that Coverity is complaining about this 
correctly, in its view of the world.  Compilers sometimes complain about 
this, too, although in this case they apparently don't look quite as 
deeply to do this analysis.

What I'm missing here is, essentially where the previous thread stopped: 
What is the overall message that we want to communicate with the API?

If the default assumption is that what pointers converted to Datums 
point to should not be modified on the other side (where the Datum is 
converted back to a pointer), then the current declaration of 
PointerGetDatum() is suitable, and the GIN code can be considered an 
exception and we make a special API for that.  The previous thread 
proposed NonconstPointerGetDatum().

(If this is the resolution, I also have half a patch somewhere that 
makes the string input argument for the InputFunctionCall family of 
functions const, which also seems intuitively sensible.)

If, on the other hand, the decision is that there is in fact no such 
guarantee, that consumers of Datums are free to modify whatever they 
seem fit, then we should drop the const of PointerGetDatum and fix the 
fallout up the call stack.

The macro proposed by Heikki, I don't know, still doesn't actually 
answer this question, just (possibly) makes these warnings go away in a 
slightly mysterious way.