[postgis-devel] geography_columns + geometry_columns

Paragon Corporation lr at pcorp.us
Wed Nov 18 20:05:09 PST 2009

 I meant view :)

-----Original Message-----
From: Paragon Corporation [mailto:lr at pcorp.us] 
Sent: Wednesday, November 18, 2009 11:05 PM
To: 'PostGIS Development Discussion'
Subject: RE: [postgis-devel] geography_columns + geometry_columns

No can't think of a reason, except not sure about the name of table maybe
the table should be called st_geometry_columns like the way db2 calls it,
but I suppose that would be a breaking change (or we could have both names)


I think the only other issue is apps that directly insert into that table
(not using our management functions).  I suppose our management functions
can become dwarfs and do nothing except add the colum though they would just
exist for legacy anyway.


-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Paul
Sent: Wednesday, November 18, 2009 10:09 PM
To: postgis-devel at postgis.refractions.net
Subject: [postgis-devel] geography_columns + geometry_columns

This is more of a 2.0 idea, since ideally it depends on having typmod
support everywhere, but I am trying to think if there's any reason not to
unify geometry_columns and geography_columns into a single view (probably
called geometry_columns, but with an extra column to flag type differences
for apps that care). 

In general naive applications that don't understand geography can still
treat is at geometry-with-epsg-4326 and get perfectly respectable results,
and that's all the metadata table is used for, so... any reason not to add
this as a 2.0 task?


Paul Ramsey
OpenGeo - http://opengeo.org
PostGIS is Love.

postgis-devel mailing list
postgis-devel at postgis.refractions.net

More information about the postgis-devel mailing list