Re: Define DatumGetInt8 function.

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.