Feedback-ID: id4a34324:Fastmail
Date: Thu, 16 Apr 2026 10:43:04 -0400
From: Andres Freund <andres@anarazel.de>
To: pgsql-hackers@lists.postgresql.org,
 Peter Eisentraut <peter@eisentraut.org>,
 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>
Subject: Re: Reduce build times of pg_trgm GIN indexes
User-Agent: K-9 Mail for Android
In-Reply-To: <4c1f88d7-5102-45b3-94e3-86d7e4b46b0a@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>
 <2197023.1776288324@sss.pgh.pa.us>
 <4c1f88d7-5102-45b3-94e3-86d7e4b46b0a@eisentraut.org>
Message-ID: <3038C8A0-6C5F-45B2-ACB2-329DABB4A1E1@anarazel.de>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/3038C8A0-6C5F-45B2-ACB2-329DABB4A1E1%40anarazel.de>
Precedence: bulk

Hi,=20

On April 16, 2026 4:45:55 AM EDT, Peter Eisentraut <peter@eisentraut=2Eorg=
> wrote:
>On 15=2E04=2E26 23:25, Tom Lane wrote:
>> Peter Eisentraut <peter@eisentraut=2Eorg> writes:
>>> On 15=2E04=2E26 13:06, Heikki Linnakangas wrote:
>>>> This was briefly discussed when PointerGetDatum() was changed from a
>>>> macro to a static inline function [1]=2E On that email, Peter pointed=
 out
>>>> that the compiler was doing the same deduction that Coverity did now,
>>>> i=2Ee=2E that if you pass the Datum returned by PointerGetDatum(&foo)=
 to a
>>>> function, it cannot change *foo=2E I'm surprised we dismissed that wo=
rry
>>>> so quickly=2E If the compiler optimizes based on that assumption, you=
 can
>>>> get incorrect code=2E
>>=20
>>> I don't think this is in evidence=2E  AFAICT, it's just Coverity that =
is
>>> complaining here, which is its right, but the code is not incorrect=2E
>>=20
>> 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=2E
>>=20
>> I think we should at least test the theory that changing
>> PointerGetDatum to remove the const cast would silence Coverity's
>> complaint=2E  If it does not then we're attributing too much
>> intelligence to Coverity=2E  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)=2E
>
>I think it's quite clear to me that Coverity is complaining about this co=
rrectly, in its view of the world=2E  Compilers sometimes complain about th=
is, too, although in this case they apparently don't look quite as deeply t=
o do this analysis=2E
>
>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 su=
itable, and the GIN code can be considered an exception and we make a speci=
al API for that=2E  The previous thread proposed NonconstPointerGetDatum()=
=2E

To me it seems way way way to dangerous to just redefine what PointerGetDa=
tum() means for all existing callers, without doing an exhaustive verificat=
ion of all the callers=2E

Separately from that, it doesn't seem defensible to take a const pointer a=
nd return a non const one=2E Why is that sane?=20

Greetings,=20

Andres
--=20
Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E