MIME-Version: 1.0
References: 
 <CAHewXNmcXVFdB9_WwA8Ez0P+m_TQy_KzYk5Ri5dvg+fuwjD_yw@mail.gmail.com>
 <CAApHDvrSSeLNWzQWWcLfZKWwHd=XocVs3abmTmvaSD_sx-dkNQ@mail.gmail.com>
 <CAHewXNkO0NO4+98=E=QodAUz_mkX2YOB0rD_C3Yz7o383aRhVQ@mail.gmail.com>
 <CAApHDvpQ4HhHDqjXZBRMan_BTrk_qerq9YiUkZTg6ZqswkHBcA@mail.gmail.com>
In-Reply-To: 
 <CAApHDvpQ4HhHDqjXZBRMan_BTrk_qerq9YiUkZTg6ZqswkHBcA@mail.gmail.com>
From: Tender Wang <tndrwang@gmail.com>
Date: Tue, 24 Mar 2026 11:07:59 +0800
Message-ID: 
 <CAHewXNmCEj2JZEjt85MXiQxhYjARP5667c_46Z7k1XySK-ikwg@mail.gmail.com>
Subject: Re: Fix "could not find memoization table entry"
To: David Rowley <dgrowleyml@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAHewXNmCEj2JZEjt85MXiQxhYjARP5667c_46Z7k1XySK-ikwg%40mail.gmail.com>
Precedence: bulk

David Rowley <dgrowleyml@gmail.com> =E4=BA=8E2026=E5=B9=B43=E6=9C=8824=E6=
=97=A5=E5=91=A8=E4=BA=8C 10:39=E5=86=99=E9=81=93=EF=BC=9A
>
> On Tue, 24 Mar 2026 at 14:10, Tender Wang <tndrwang@gmail.com> 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 =3D -1;
>         uint64_t i64 =3D (uint64_t) i32;
>
>         for (int i =3D 0; i < 64; i++)
>         {
>                 putchar(i64 & 0x8000000000000000ULL ? '1' : '0');
>                 i64 <<=3D 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 wi=
ll
         * not do the work, because we do not know how these bytes are alig=
ned
         * inside the "Datum".  We assume instead that any given datatype i=
s
         * consistent about how it fills extraneous bits in the Datum.

Using sizeof(Datum) in datum_image_hash() is totally correct.


--=20
Thanks,
Tender Wang