Message-ID: <b25bd9ff-3d18-4d23-a480-17434096fab1@iki.fi>
Date: Fri, 17 Apr 2026 22:21:41 +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>
 <37ce5cce-66ca-4216-ae88-af39c444042d@iki.fi>
 <2438252.1776361625@sss.pgh.pa.us>
Content-Language: en-US
From: Heikki Linnakangas <hlinnaka@iki.fi>
In-Reply-To: <2438252.1776361625@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/b25bd9ff-3d18-4d23-a480-17434096fab1%40iki.fi>
Precedence: bulk

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.

Grepping for PointerGetDatum(), there are a bunch of wrappers of it for 
specific types, like:

static inline Datum CStringGetDatum(const char *X)
static inline Datum NumericGetDatum(Numeric X)

Most are marked "const". These all potentially have the same problem, 
but I think for these it is a good assumption that resulting Datum will 
not be used to modify *X, so we can leave them alone. I guess we didn't 
do that for NumericGetDatum just because the Numeric typedef doesn't 
allow that.

There's also:

static inline Datum fetch_att(const void *T, bool attbyval, int attlen)

The "const" seems reasonable on that too.

This is an interesting case:

static inline Datum
EOHPGetRWDatum(const struct ExpandedObjectHeader *eohptr)
{
	return PointerGetDatum(eohptr->eoh_rw_ptr);
}

That RW stands for read/write, which sounds alarming. But the returned 
datum points to eohptr->eoh_rw_ptr rather than *eohptr itself, so I 
think the 'const' is correct here after all.

So, pushed a commit that changes just PointerGetDatum() itself, leaving 
all those others alone.

- Heikki