Feedback-ID: ie0a040ee:Fastmail
Message-ID: <b9df26bc-b19d-4d73-82ae-1ebb6d34dfd4@eisentraut.org>
Date: Fri, 27 Mar 2026 13:17:15 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Define DatumGetInt8 function.
To: Aleksander Alekseev <aleksander@tigerdata.com>,
 pgsql-hackers <pgsql-hackers@postgresql.org>
Cc: Kirill Reshke <reshkekirill@gmail.com>,
 David Rowley <dgrowleyml@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>
References: 
 <CALdSSPhFyb9qLSHee73XtZm1CBWJNo9+JzFNf-zUEWCRW5yEiQ@mail.gmail.com>
 <2869012.1767023578@sss.pgh.pa.us>
 <CALdSSPg6UgK+6LJmFQ6G3av4J6dbngN7=QwQEuFZApnpmXgVWQ@mail.gmail.com>
 <CAApHDvoShMiWPSkV8zE3tu7uo9GEmuoe=gTpM0+GfOFh2iDmmw@mail.gmail.com>
 <CALdSSPjmukA1WGyYVqJMPD8080Rm9oXPVLn5T64xFCj6wKAenQ@mail.gmail.com>
 <CAJ7c6TPsaLW7O67vqv8YyV_qUUjF0pncDB7dCQJFDw0so7wrdw@mail.gmail.com>
 <CALdSSPjSaTvQL28csVo-8hNg8xJ5=YFr6qwtF=JAMLb1eJO2gQ@mail.gmail.com>
 <CAJ7c6TM4zecvHj0F9Xk-V1gKqjYQOR4EjerTVkrZ18+w-6JN3Q@mail.gmail.com>
 <7f39480a-4b7a-4a51-a9ec-d1189b44432d@eisentraut.org>
 <CAJ7c6TMcGu8qmRe1gZfJ-gOzVnZq-t=fwn-UuyStx1w6ZyydMw@mail.gmail.com>
Content-Language: en-US
From: Peter Eisentraut <peter@eisentraut.org>
In-Reply-To: 
 <CAJ7c6TMcGu8qmRe1gZfJ-gOzVnZq-t=fwn-UuyStx1w6ZyydMw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/b9df26bc-b19d-4d73-82ae-1ebb6d34dfd4%40eisentraut.org>
Precedence: bulk

On 13.03.26 11:55, Aleksander Alekseev wrote:
> Hi Peter,
> 
> Thanks for your feedback.
> 
>> I'm tempted to think the correct direction here would be to use uint8
>> and its associated macros and functions more rigorously, not less.
> 
> OK, if my understanding is correct this leaves us char_increment() and
> char_decrement() which currently use DatumGetUInt8 inconsistently with
> CharGetDatum for the argument and return value correspondingly.
> 
>> I don't think it's worth making an isolated fix here for the one use of
>> UInt8GetDatum()
> 
> I think you meant not this particular change so I included it to the
> patch. We can keep nbtcompare.c as if you believe this change is not
> that important (it arguably isn't).
> 
>> The change in pageinspect looks correct, but then when you look
>> nearby and further around, you will find that there are also a bunch of
>> (if not most) UInt16GetDatum and UInt32GetDatum that are wrong
>> [...]
> 
> Agree. I did my best to fix all the inconsistencies in pageinsect.
> 
>> There are a lot of opportunities to clean this up, and I suspect that
>> while many of these will work either way in practice because the actual
>> values don't go far enough to hit the signed/unsigned boundary, I think
>> there could a number of little bugs here to be fixed.
> 
> I believe you were referring to places other than pageinspect. I will
> investigate and create separate threads with corresponding patches
> later.

I'm moving this patch to the next commitfest.  It's worth continuing to 
work on making this more correct, but AFAICT no bug has been claimed 
here, so it's not worth rushing this now.