Caleb.
I'd like to see this topic revisited since as far as I can see it hasn't been seriously discussed in years. I believe the main arguments against are why do we need more more numeric datatypes and increased maintenance. It would seem to me that a tinyint datatype maintenance wise would get all the same updates as the other int types, making it only a slight increase in maintenance. I think there was 1 more reason but I can't find the original thread now.
The main reason not to have one is that given byte-alignment, 95% of the time using a tinyint would save no actual disk space or memory over just using INT2 (or indeed INT4). I'll point out that the MySQLers are enamored of the 3-byte integer, which even on MySQL saves zero space or memory over using a 4-byte. Just because people like it doesn't mean it works.
So the only real point in having an INT1 would be if you had a table with a lot of them in a row; an unusual but not unheard-of design. Still, that makes this feature less-than-critical for most users.
But ... the nice thing about PostgreSQL is that data types can be loaded at runtime. Which means that you don't need INT1 in core for it to be useful to you and others; just write the data type and put it on pgFoundry. Then submit it for /contrib for 8.5, and we'll see how popular the idea is.
Overall, I'm not keen on it. For the handful of times when peformance-optimization-by-datatype makes sense, there's a large number where it's develpers who have no idea what they're doing. We should be moving in the direction of having the database engine take care of space optimizations, not having the user do it.
-- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
