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