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

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > Would this allow for 'multi-value' typmods for user-defined types?
>
> If you can squeeze them into 31 bits of stored typmod, yes. That
> may mean that you still need the side table (with stored typmod being a
> lookup key for the table). But this gets you out of exposing that
> detail to users.

I see, the user could put in:
geometry(123456789,MULTIPOLYGON,3);

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.

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

Thanks!

Stephen