[postgis-devel] [postgis-users] how to keep geometry_columns in sync wit tablesand views (and new PostGIS 2.0 plans)
lr at pcorp.us
Fri May 20 13:01:03 PDT 2011
ST_geometry_columns - for those who wish for purity -- anyone :)
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
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.
From: postgis-users-bounces at postgis.refractions.net
[mailto:postgis-users-bounces at postgis.refractions.net] On Behalf Of Paul
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.
On Fri, May 20, 2011 at 4:26 AM, Sandro Santilli <strk at 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...
> () Free GIS & Flash consultant/developer
> /\ http://strk.keybit.net/services.html
> postgis-users mailing list
> postgis-users at postgis.refractions.net
postgis-users mailing list
postgis-users at postgis.refractions.net
More information about the postgis-devel