Re: Rethinking user-defined-typmod before it's too late

On Fri, 2007-06-15 at 15:01 -0400, Stephen Frost wrote:

> But we'd only get 31 bits of room to encode that into.  I'm not sure if
> that's enough. :(  At the moment there's three columns we're talking
> about in the side-table:
> SRID (integer)
> TYPE (varchar(30))
> DIMENSIONS (integer)
> 
> Now, the type is a small enumerated set, and we can probably limit
> dimensions to a few bits (maybe one for 2d/3d, but we might have some
> other cases...), and still be following the OGC standard, but I don't
> think there are any restrictions on SRID beyond '32 bit integer'.  As
> such, I'm not sure if we can encode it all directly into 31 bits (which
> would obviously be preferred to a side-table with each case we come
> across being enumerated in it).  Then again, at the *moment*, anyway,
> the SRIDs we have only go up to about 32,000, so we could dedicate 16
> bits to it and probably be alright.

This is for type/column definitions, so you'd only have a problem if you
had more than 2 billion defined combinations of (SRID, TYPE, DIMENSIONS)
in the database. Admittedly this would need to cope with all user
defined typmods created during SQL execution e.g. X::typmod(A, B, C),
but ISTM that would never realistically be a problem.

The typmod function could cache the top ten combinations etc..

> Any chance of this being increased?  Obviously would like to avoid the
> side-table, if possible.

If you had more than 2 billion permutations you'd definitely want that
in a table.

--  Simon Riggs              EnterpriseDB   http://www.enterprisedb.com