Re: tinyint and type problems

Shachar Shemesh <psql(at)shemesh(dot)biz> writes:
> I have sent a patch to implement tinyint, an unsigned one byte integer,
> ...
> Now, I'm not against neither simplifying the type system nor having a
> "unsigned" keyword. The thing is that between these two remarks, my
> patch was not applied and I don't know why.

> I need this new type because ...

Um, the reason we have an extensible type system is so that people can
make their own datatypes. You don't have to get a type accepted into
the base system in order to use it yourself. There wasn't any part of
your patch that couldn't have been implemented like a contrib module
(i.e., a dynamically loaded library for the C functions plus a SQL
script to install the catalog entries).

The criterion for adding new types to the base system is really "is this
of sufficient general usefulness to justify taking on a permanent
maintenance load?" ... where the size of the maintenance load depends
quite a lot on how tightly bound the new type is to the rest of the
system. A new type that is part of the numeric hierarchy is going to be
way up there on the scale of maintenance burden. For instance, people
would expect it to have at least as much functionality as int2 does,
such as indexing support, and so we'd be buying into (sooner or later)
doing a lot of work that your patch left unfinished.

On top of that there are some concerns about locking ourselves into
supporting a definition we might not like later. Most obviously there
is the signed/unsigned issue, but that's not the only risk. We are still
tweaking the numeric hierarchy to try to get the interrelationships of
the types just right. Until we are really satisfied that that task
is done, I'm not excited about adding more functionality that might look
like a big backwards-compatibility problem later.

So the bottom line for me is that the potential downsides outweigh
the upside. You haven't made a good enough case for the general
usefulness of this datatype.

regards, tom lane