Repository files navigation

This extension provides additional integer types for PostgreSQL:

• int1 (signed 8-bit integer)
• uint1 (unsigned 8-bit integer)
• uint2 (unsigned 16-bit integer)
• uint4 (unsigned 32-bit integer)
• uint8 (unsigned 64-bit integer)

PostgreSQL version 9.2 or later is required. Currently, only 64-bitbuilds are supported.

To build and install this module:

makemake install

or selecting a specific PostgreSQL installation:

make PG_CONFIG=/some/where/bin/pg_configmake PG_CONFIG=/some/where/bin/pg_config install

And finally inside the database:

CREATE EXTENSION uint;

You can use the new types like the standard integer types. Examples:

CREATETABLEfoo (    a uint4,    btext);SELECT*FROM fooWHERE a>4;SELECTavg(a)FROM foo;

The types come with a sizable set of operators and functions, indexsupport, etc. Some pieces are still missing, but they are beingworked on. If there is anything you can't find, let me know.

Support for unsigned integer types and smaller integer types has beenone of the more common outstanding feature request for PostgreSQL.Inclusion of additional integer types into the core is typicallyrejected with the argument that it would make the type system toocomplicated and fragile. The experience from writing this modulesuggests: That is not wrong. Another argument, either explicit orimplicit, is that it is a lot of work. Again: true.

The combination of the requirements of the SQL standard and the typesystem of PostgreSQL effectively create a situation where you need toprovide a comprehensive set of operators and functions foreachcombination of numeric types. So for the three standard integertypes, that's 9 "+" operators, 9 "<" operators, and so on. And with3 + 5 = 8 types, well, you do the math. This module solves thatproblem by generating most of the code automatically.

The purpose of this module is therefore twofold: First, it should beuseful in practice. There is no reason why it couldn't be. Second,it is a challenge to the PostgreSQL extension mechanism. In thatarea, there are various "interesting" problems that still need to beworked out.

In addition to the test suite of this module (make installcheck), itis useful to test this module by running the main PostgreSQLregression tests while this module is loaded, which should not fail.This will verify that the presence of the additional types andoperators will not cause changes in the interpretation of expressionsinvolving the existing types and operators.