David Rowley <[email protected]> 于2026年3月24日周二 10:39写道：
>
> On Tue, 24 Mar 2026 at 14:10, Tender Wang <[email protected]> wrote:
> > Actually, I haven't quite figured out why `typLen` cannot be used here.
>
> This is because we sign-extend rather than zero-extend up to Datum.
> Consider this code from master:
>
> typedef uint64_t Datum;
>
> static inline Datum
> Int32GetDatum(int32 X)
> {
> return (Datum) X;
> }
>
> So we cast to uint64_t when converting int32 to Datum.
>
> And consider the output of this C program:
>
> drowley@amd3990x:~$ cat datum.c
> #include <stdio.h>
> #include <stdint.h>
>
> int main(void)
> {
> int32_t i32 = -1;
> uint64_t i64 = (uint64_t) i32;
>
> for (int i = 0; i < 64; i++)
> {
> putchar(i64 & 0x8000000000000000ULL ? '1' : '0');
> i64 <<= 1;
> }
> putchar('\n');
> return 0;
> }
>
>
> drowley@amd3990x:~$ gcc datum.c -o datum && ./datum
> 1111111111111111111111111111111111111111111111111111111111111111
>
> If you only look at the lower 32 bits of that Datum, then you're not
> looking at the entire value.
Got it. Thanks for your explanation.
> I don't have hardware to try it, but I also don't suppose comparing
> the first attlen bytes of a Datum does the same thing on big-endian
> machines as that would look at the most significant side of the Datum
> rather than the least significant side as it would on little-endian.
I find comments in datumIsEqual() when typByVal is true:
* just compare the two datums. NOTE: just comparing "len" bytes will
* not do the work, because we do not know how these bytes are aligned
* inside the "Datum". We assume instead that any given datatype is
* consistent about how it fills extraneous bits in the Datum.
Using sizeof(Datum) in datum_image_hash() is totally correct.
--
Thanks,
Tender Wang
