Message-ID: <1586347e-2afd-4268-9a6e-03e0b6f8c788@iki.fi>
Date: Thu, 23 Apr 2026 00:11:51 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Reduce build times of pg_trgm GIN indexes
From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter@eisentraut.org>,
 pgsql-hackers <pgsql-hackers@postgresql.org>,
 David Geier <geidav.pg@gmail.com>
References: <5d366878-2007-4d31-861e-19294b7a583b@gmail.com>
 <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>
 <37ce5cce-66ca-4216-ae88-af39c444042d@iki.fi>
 <2438252.1776361625@sss.pgh.pa.us>
 <b25bd9ff-3d18-4d23-a480-17434096fab1@iki.fi>
Content-Language: en-US
In-Reply-To: <b25bd9ff-3d18-4d23-a480-17434096fab1@iki.fi>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/1586347e-2afd-4268-9a6e-03e0b6f8c788%40iki.fi>
Precedence: bulk

On 17/04/2026 22:21, Heikki Linnakangas wrote:
> On 16/04/2026 20:47, Tom Lane wrote:
>> Heikki Linnakangas <hlinnaka@iki.fi> writes:
>>> On 16/04/2026 17:37, Tom Lane wrote:
>>>> Not excited about making massive changes for this.
>>
>>> Having all three would be a very localized change in postgres.h.
>>
>> Sure, but *using* them in a consistent way would be invasive.
>>
>>>> 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?
>>
>> WFM.
> 
> ...
> 
> So, pushed a commit that changes just PointerGetDatum() itself, leaving 
> all those others alone.

As we thought, this made the Coverity warning go away.

I'm happy with the status quo in master, but if we want to introduce new 
ConstPointerGetDatum() or NonConstPointerGetDatum() variants instead of 
the macro, now is the time to do it.

For backbranches, IMHO we should go with the macro. It's a little scary 
to replace such a widely used function as PointerGetDatum() in 
back-branches, but I do think this should be fixed. Introducing new 
variants doesn't seems even less backpatchable.

- Heikki