In my mind, the *only* reason I'm spending the time to implement typmod is to turn geometry_columns into a view. If I'm not getting that, it's not worth spending the time. The whole point, for me, is that I can CREATE TABLE and boom my data shows up. There should not be any required manual steps in general operation. I can just *barely* get behind having a manually managed side table that gets unioned with geometry_columns for lunatics who want to hand-enter their own stuff, but in ordinary operations geometry_columns should just be magically up-to-date at all times.
P. On Fri, May 20, 2011 at 4:26 AM, Sandro Santilli <s...@keybit.net> wrote: > 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 > _______________________________________________ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
