David Fetter wrote:
For my vote, I'd prefer either the Oid of a custom type or an array
of Oid, Datum pairs - i.e. something we can extend in the future if
required.
This sounds a lot like a foreign key to another table. Are you not
proposing doing that because of performance considerations?
Cheers,
David.
Well, in PostGIS a typmod contains 3 pieces of information:
1) the SRID
2) the dimension
3) the geometry type
The SRID is technically already a foreign key into another table, with
dimension and SRID as other information. At the moment, we bit-pack the
dimension and geometry type into the SRID and use that as the typmod but
this only leaves 21 bits IIRC for the SRID. The additional complication
is that SRIDs at the higher end of the range are allowed for anyone to
use, and so people may have their own customised spheroids defined in
this region of the table.
If we had a foreign key into another table, we'd need to ensure that no
one could tamper with it as otherwise all chaos would break lose, e.g.
breaking the geometry type constraint on a column. Heck, we even have
people deleting the geometry_columns table sometimes because they are
not aware of what it does. By storing this information in the PG catalog
then this can't happen, plus the information is available easily in
Form_pg_attribute without having to implement our own cache, with its
own related problems such as how/when to invalidate etc.
There is also a chance that we'd want to include additional information
in the future related to geometry validity, for example, which would
mean further reducing the range allowed within the spatial_ref_sys table
in its existing form.
ATB,
Mark.
--
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063
Sirius Labs: http://www.siriusit.co.uk/labs
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
