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 _______________________________________________ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
