[postgis-users] What's the Purpose of the Geometry_Columns Table?

[strk at refractions.net]

On Tue, Sep 05, 2006 at 10:50:32AM -0400, Stephen Frost wrote:

> At first glance it looks like the geometry_columns could be based off
> the pg_class, pg_attribute, and pg_type system tables by just looking
> for tables which have columns of type 'geometry'.  I see that
> geometry_columns also contains the number of dimensions, the srid, and
> the type.  Are all three needed?  Can any of them be pulled from the
> table directly?  Would they perhaps make more sense as individual types
> instead of having just the one 'geometry' type?
> 

> I especially wonder about the last as the values in those columns appear
> to be enforced through check constraints generally anyway...  Perhaps
> what we need is an easy way to define new types and some appropriate
> casting functions for them instead of attempting to munge all the,
> apparently distinct, types into one.

A single view would make it possible.
Problem is performance: do we want to scan all tables ?

If we don't we might look at constraints, which have been appropriately
named for specifically this purpose since about 1.0.0.
Still, we would miss info on some "manually" added columns (not trouhg
AddGeometryColumn).

Since I think the point is completely doing w/out "certified" annoyances :)
What I was up to in the past was:

	1. define domains for specific types

So far PostgreSQL won't allow us to use types like: ST_Point(3, 4326)
We would need that to encode SRID and dimension inside the domain record
thus making unecessary both the constraints *and* the spatial tables scans
from geometry_columns views.

Note that we might encode dimensions in the domain name:
POINT2D, POINT3DM, POINT3DZ, POINT4D
Still, we'd miss SRID information.

--strk;