On Wed, Sep 06, 2006 at 12:50:20PM -0400, Stephen Frost wrote:
> The information for each attribute is:
>
> Number of dimensions
> Spatial Referencing System (identified by the SRID)
> Type (ie: Point, Polygon, etc)
<snip>
> POINT(dims, srid) - eg: POINT(2,4269)
> geometry(dims, srid, type) - eg: geometry(2,4269,'POINT')
> POINT_2D(srid) - eg: POINT_2D(4269)
> geometry - eg: geometry (constraints, side-table)
>
> SRID is pretty uniformly defined to be an int4 itself, though the
> PostGIS folks seemed to think it could be cut to 30-bits (2 bits for
> dimension is enough for them) if necessary.
User-defined typmod would be cool. As long as you don't want to rely on
the typmod to decode the Datums, it's really just a grammer change. I
proposed a while ago that users be allowed to provide a function that
converts the extra params into an int32 which is the actual typmod.
So the point type would be declared as having a typmod function
"point_typmod". So you could have point_typmod(int4) and
point_typmod(int4,int4) to handle both cases. I don't think we should
be tied to only integers as parameters, I'd like to be able to do:
CREATE TABLE ... ( string_field text('latin1'), ...
Whether that's a good way to do that particular feature, I don't know,
but if it's possible I think that would indicate our system is flexable
enough.
Someone posted a patch to the grammer which seemed to work, I don't
think in and of itself it is very difficult. As long as you don't want
to have the typmod to avoid storing data in the datum (which the
raw(64) example is) it should be fairly straightforward...
Hope this helps,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.
