Message-ID: <37ce5cce-66ca-4216-ae88-af39c444042d@iki.fi>
Date: Thu, 16 Apr 2026 20:30:51 +0300
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: Peter Eisentraut <peter@eisentraut.org>, 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>
 <4c1f88d7-5102-45b3-94e3-86d7e4b46b0a@eisentraut.org>
 <99ce20a5-793a-4182-9120-f274fbef9bfd@iki.fi>
 <2340004.1776350271@sss.pgh.pa.us>
Content-Language: en-US
From: Heikki Linnakangas <hlinnaka@iki.fi>
In-Reply-To: <2340004.1776350271@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/37ce5cce-66ca-4216-ae88-af39c444042d%40iki.fi>
Precedence: bulk

On 16/04/2026 17:37, Tom Lane wrote:
> Heikki Linnakangas <hlinnaka@iki.fi> writes:
>> On 16/04/2026 11:45, Peter Eisentraut wrote:
>>> 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?
> 
> Good point.
> 
>>> 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().
> 
> I think there can be no doubt that most functions receiving a
> pass-by-ref Datum are not supposed to scribble on the pointed-to
> data.  So it makes sense to me that PointerGetDatum should carry
> an implication of const-ness, and then we need to invent a new
> notation to use in the small number of places where that's not
> appropriate.  I'd capitalize it as NonConstPointerGetDatum,
> but other than that nit that naming suggestion seems fine to me.

That makes sense. My worry is that we're changing the rules in a very 
subtle way: It used to be OK to use PointerGetDatum(), pass the 
resulting datum to something that modifies it. Now we say it's not OK, 
and you must use NonConstPointerGetDatum(). You don't get any compiler 
warnings if you use it wrong, except for this one coverity warning 
apparently, but it doesn't catch this reliably either.

> Of course, then the *real* question is why DatumGetPointer
> doesn't deliver a const pointer.  But I don't see how to get
> there without extremely invasive changes.

Good point.

>> We could have all three:
> 
> Not excited about making massive changes for this.

Having all three would be a very localized change in postgres.h.

> I remain far less certain than Peter is that this discussion has
> anything to do with why Coverity is complaining about
> ginExtractEntries.  I still think we should make some minimum-effort
> change to see if the complaint goes away before expending a lot of
> brain cells on choosing a final fix.

I think I'm going to commit my proposal to turn PointerGetDatum() back 
into a macro, and see if that makes Coverity happy. Then we'll know, and 
we can decide on the next steps. Any objections?

One open question is whether we should backpatch any of this. I guess 
compilers don't misoptimize this in practice, or we would've gotten more 
reports, but I really can't rationalize why not and a new compiler 
version might well start hitting this.

- Heikki