[postgis-devel] [postgis-users] how to keep geometry_columns in sync wit tablesand views (and new PostGIS 2.0 plans)
strk at keybit.net
Fri May 20 01:26:25 PDT 2011
On Fri, May 20, 2011 at 03:15:26AM -0400, Paragon Corporation wrote:
> One other note -- the SQL/MM standard calls for an st_geometry_columns view
> which is a true view that reads the system catalogs and should only read the
> system catalogs I think.
> geometry_columns is a left over from OGC standard. So my other point is if
> we are going to do things the new way, why don't we call it the new name
> So that is why I was proposing a hybrid -- geometry_columns -- so new
> PostGIS can work with older tools
> and st_geometry_columns -- which will be strictly pure new way.
> Though I suppose that may be more confusing than it's worth and there is the
> case of views
Yeah, think about all clients, it would be an hell of configuration to
tell qgis wheter or not to look in st_geometry_columns and/or geometry_columns
and in which order etc. etc.
My opinion is starting to form on this and currently is closer to
"maintain a real table".
typmod might make _populating_ the table easier, and you could still
add entries manually in case there's no way to tell automatically
(due to loose typemod, for example). Also, a real table might let
you add fields for XML metadata to associate to "layers", which we
might account for in 2.0.
Now, we could keep/alter geometry_columns (to add maybe also an identifier
for each layer rather than using a 3/4 columns unique key...) and have
a lame ST_geometry_columns view as naked as ISO likes it, but still querying
the real geometry_columns table.
This is basically suggesting we do _not_ make a view to tell which spatial
layers exist, but we can provide a function to do that, which may be used
but the geometry_column population function...
() Free GIS & Flash consultant/developer
More information about the postgis-devel