[postgis-devel] [postgis-users] how to keep geometry_columns in sync wit tablesand views (and new PostGIS 2.0 plans)

[Sandro Santilli]

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
> "st_geometry_columns"
>  
> 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...

--strk; 

  ()   Free GIS & Flash consultant/developer
  /\   http://strk.keybit.net/services.html