Re: Support for unsigned integer types

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jack Bay <jack(dot)victor(dot)bay(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Support for unsigned integer types
Date: 2024-12-07 16:24:37
Message-ID: 3180774.1733588677@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jack Bay <jack(dot)victor(dot)bay(at)gmail(dot)com> writes:
> Would it be possible to add support for unsigned 64-bit and unsigned
> 32-bit integers to postgresql?

This has been discussed before, and we've concluded that the impact
on the numeric promotion hierarchy (that is, implicit-cast rules
among the integer types) would probably be catastrophic, leading
to problems like ambiguous-operator errors in many cases that were
fine before. Quick, is "42 + 1" an int32 or uint32 operation?

That could be avoided perhaps by measures like not having any
implicit casts between the int and uint hierarchies, but then
there'd be a corresponding loss of usability for the uint types.

Plus, the sheer magnitude of effort needed to build out a reasonable
set of support (functions, operators, opclasses) for uint types seems
daunting.

On the flip side, it'd be great to be able to use uint32 instead
of bigint for the SQL representation of types like BlockNumber.
But we couldn't roll in such a change transparently unless we make
int-vs-uint casting fairly transparent, which seems problematic
as per above.

Perhaps a sufficiently determined and creative person could put
together a patch that'd be accepted, but it'd be a lot of work
for uncertain reward. I'm not aware that anyone is working on
such a thing at present.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jack Bay 2024-12-07 16:51:54 Re: Support for unsigned integer types
Previous Message Devulapalli, Raghuveer 2024-12-07 15:16:05 RE: Proposal for Updating CRC32C with AVX-512 Algorithm.