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>
In-Reply-To: 
 <CAHewXNkO0NO4+98=E=QodAUz_mkX2YOB0rD_C3Yz7o383aRhVQ@mail.gmail.com>
From: David Rowley <dgrowleyml@gmail.com>
Date: Tue, 24 Mar 2026 15:39:40 +1300
Message-ID: 
 <CAApHDvpQ4HhHDqjXZBRMan_BTrk_qerq9YiUkZTg6ZqswkHBcA@mail.gmail.com>
Subject: Re: Fix "could not find memoization table entry"
To: Tender Wang <tndrwang@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
 <https://www.postgresql.org/message-id/CAApHDvpQ4HhHDqjXZBRMan_BTrk_qerq9YiUkZTg6ZqswkHBcA%40mail.gmail.com>
Precedence: bulk

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 = -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.

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.

David