On Tue, May 20, 2025 at 11:28:17PM +1200, David Rowley wrote: > Certainly, a bit late, yes. It basically requires implementing > unsigned types on the SQL level. I believe there are a few sunken > ships along that coastline, and plenty of history in the archives if > you want to understand some of the difficulties.
Providing some more context and some more information than this reply, the latest thread that I can find on the matter is this one, from December 2024: https://www.postgresql.org/message-id/CAN3gO4sPBKbfWYK10i294u3kzsfDb4WX891FMbjLnKjMS08u7A%40mail.gmail.com It summarizes nicely the situation and it contains some more general points. This particular point from Tom about numeric promotion and casting hierarchy resonates as a very good one: https://www.postgresql.org/message-id/3180774.1733588677%40sss.pgh.pa.us My own bet is that if you don't want to lose any existing functionality, perhaps we should be just more aggressive with casting requirements on input to begin with even if it means more work when writing queries, even if it comes at a loss of usability that should still be something.. FWIW, I've wanted an unsigned in-core type more than once. It would be a lot of work, but we have a lot of things that exist in the core code that map to unsigned 32b or 64b integer values. Just naming one, WAL LSN difference calculations. XLogRecPtr is a 64b unsigned value, not its representation at SQL level, meaning that we'd overflow after reaching the threshold of the bit tracking the signedness. It's true that a system would need to live long enough to reach such LSNs, but we have also 32b integers plugged here and there. Another one is block numbers, or OID which is an in-core type. Having an in-core unsigned integer type would scale better that creating types mapping to every single internal core concept. -- Michael
signature.asc
Description: PGP signature
