>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.
In my opinion no explicit cast between unsigned and signed integer is very desirable behavior. >Quick, is "42 + 1" an int32 or uint32 operation? Or is it int64 or uint64, when should it overflow? Or is it a floating point operation? Or are there mismatched numeric types, because one is a float and the other is an integer? In this circumstance, most likely 42 would be a variable with a known type so you could deduce the intended type of 1 which presumably is a constant. This gets into questions around the SQL type system I am unfamiliar with. > ambiguous-operator errors in many cases that were fine before. Adopt a convention that integers are signed unless explicitly made unsigned? To be explicit, you could write 42u64 + 1u64 or 42u32 + 1u32... On Sat, Dec 7, 2024 at 8:24 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Jack Bay <jack.victor....@gmail.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
