From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter@eisentraut.org>
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>
Subject: Re: Reduce build times of pg_trgm GIN indexes
In-reply-to: <aa908216-6ed6-4d19-b63c-a13441aeae4c@eisentraut.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>
Comments: In-reply-to Peter Eisentraut <peter@eisentraut.org>
	message dated "Wed, 15 Apr 2026 21:12:51 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2197022.1776288324.1@sss.pgh.pa.us>
Date: Wed, 15 Apr 2026 17:25:24 -0400
Message-ID: <2197023.1776288324@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2197023.1776288324%40sss.pgh.pa.us>
Precedence: bulk

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).

			regards, tom lane