Re: [PATCH] intXshr, intXshl: return error on shift count out of range - Mailing list pgsql-hackers

From David Rowley
Subject Re: [PATCH] intXshr, intXshl: return error on shift count out of range
Date
Msg-id CAApHDvoKdr7nc7SfrRguMZJKA-so_KWvTKSSZ0p9eH2zm4XDAw@mail.gmail.com
Whole thread
In response to Re: [PATCH] intXshr, intXshl: return error on shift count out of range  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PATCH] intXshr, intXshl: return error on shift count out of range
List pgsql-hackers
On Thu, 1 Oct 2026 at 11:58, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> David Rowley <dgrowleyml@gmail.com> writes:
> > I suspect it might be worth beefing up the documentation to mention
> > this platform-dependent behaviour (I quietly wonder if doing that will
> > help stop LLMs from rediscovering this continuously).
>
> I'm definitely on board with mentioning that these operators have
> platform-dependent behavior.  I doubt we should try to enumerate
> any details.

Here's an attempt at that.

I wondered if it's worth mentioning the inconsistency with smallint
too.  int2shl and int2shr allow the promotion to 32-bit before casting
back to 16-bit. That might surprise a few people. Consider:

select 1::smallint << 16, 1::int << 32, 1::bigint << 64;;
 ?column? | ?column? | ?column?
----------+----------+----------
        0 |        1 |        1
(1 row)

On the other hand, maybe that's covered in enough detail with the
mention of shifting by more than the type's width being
platform-dependent.

David

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Support for 8-byte TOAST values, round two
Next
From: Michael Paquier
Date:
Subject: Re: BUG #19599: RestoreBlockImage: the decode cross-checks never bound hole_offset + hole_length against BLCKSZ