ST_geometry_columns - for those who wish for purity -- anyone :) Paul, Are you suggesting I'm a lunatic? I'm going to check the mirror now to see if I'm growing fangs :).
I agree with you though -- that is the main beauty of typmod which is why strk's solution won't work. I would almost go with forcing everyone to change their existing tables to typmod if they want to reap the benefits of PostGIS 2.0, but most of my clients will not go to 2.0 then. We could try Mark's idea of hacking the catalog tables to automagically convert table constraints to typmod but that all sounds pretty scary to me. Especially with my special Inheritcance case -- I can just see that failing miserably and screwing up my tables. Anyrate we can't try any of these until you put in place the typmod feature. Once you put in place typmod -- I think we can exercise all the various options to see which evil is the least of all evils. Thanks, Regina -----Original Message----- From: postgis-users-boun...@postgis.refractions.net [mailto:postgis-users-boun...@postgis.refractions.net] On Behalf Of Paul Ramsey Sent: Friday, May 20, 2011 7:53 AM To: PostGIS Users Discussion; PostGIS Development Discussion Subject: Re: [postgis-users] [postgis-devel] how to keep geometry_columns in sync wit tablesand views (and new PostGIS 2.0 plans) 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 _______________________________________________ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users