Re: Porting MySQL data types to PostgreSQL

Decibel! <decibel(at)decibel(dot)org> writes:
> Be that as it may, I suspect that if someone puts forward a working set
> of uint2/4/8 it'd be considered for inclusion.

The datatypes themselves are utterly trivial. The hard part, if you
want them to be part of the numeric hierarchy, is figuring out what the
type promotion and implicit casting rules ought to be. For example,
it's far from clear what the initially-assumed type of an integral
constant ought to be. I experimented once with allowing small integer
constants to be typed as int2 rather than int4, and it was amazing how
much stuff fell over just from that --- see the archives from maybe five
years ago for details, but the problem was basically that the parser
started finding a lot of unexpected and unwanted coercion paths, leading
to either wrong results or "can't resolve ambiguous operator" errors.
Throwing various sizes of uint into the picture would make things a
whole lot worse, not least because the semantics would actually change
depending on which assumption you made.

C can sort of deal with this because it's got a fixed set of types and
a fixed set of operators, but even in C it's frighteningly easy to get
burned by the compiler assuming it should do signed comparison where you
intended unsigned or vice versa. In an extensible system like Postgres
the potential for mayhem is a lot worse.

I don't say these things are insoluble, but I do say it's a whole lot
harder than most people who ask for unsigned types realize.

regards, tom lane