Hello Tom, On Thu, Jul 24, 2008 at 10:10 PM, Tom Lane <[EMAIL PROTECTED]> wrote: > "Ryan Bradetich" <[EMAIL PROTECTED]> writes: >> I am looking to take advantage of PostgreSQL extensible type system >> and implement unsigned integer support. > > This has been proposed before, and foundered before on the question > of implicit coercions. If you're willing to make all coercions *to* > unsigned types be explicit (or at most assignment), then I think > it can be made to work without breaking anything. But usually the > folk who ask for this feature are hoping that bare integer literals > like "42" will get interpreted as unsigned when they want them to be. > The problem with that wish is illustrated by > > select 1500000000 + 1500000000; > > These literals might be either int4 or uint4, therefore this command > might yield either an integer-overflow error or 3000000000::uint4. > That's not a distinction you can fuzz over --- it's got to be one > or the other, and backwards compatibility says it'd better be the > first.
I am in agreement with you on this. Since SQL does not specify unsigned types, I was assuming only explicit and assignment casts. I should have probably mentioned that in the RFC. Thanks for pointing this out. My main goal for this type is the reduced storage space. I am fine with people needing to cast to the unsigned types to benefit from the reduced storage space. My plans for the example above would be: 1. SELECT 1500000000 + 1500000000 --> Throws overflow error. 2. SELECT 1500000000::uint4 + 1500000000 --> Returns 3000000000::uint4. > >> I am hoping the removal of many of the implicit casts in >> PostgreSQL 8.3 will simplify this task to where this objection can be >> removed. > > The implicit casts we removed were cross-type-category cases. > If you hope for unsigned types to be considered part of the numeric > category, there's no guidance for you there. In fact, the real nub > of the problem is what type shall be initially assigned to an > integer-looking literal, and how will you get things to behave sanely > if that initial choice wasn't what was desired. We still have some > issues around the fact that "42" isn't considered a smallint. Throwing > in another possible meaning isn't going to help. > >> My understanding is the SQL standard does not provide support for >> unsigned integers, so I am planning on making all casts from unsigned >> integers to other data types explicit. > > It's really the other direction that would be contentious ... > > regards, tom lane Thanks for your comments! I have already started to play around a bit with the types and will hopefully have some code ready for review / feedback soon. - Ryan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
