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

Paul Ramsey pramsey at opengeo.org
Fri May 20 04:52:49 PDT 2011

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...
> --strk;
>  ()   Free GIS & Flash consultant/developer
>  /\   http://strk.keybit.net/services.html
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users

More information about the postgis-devel mailing list