[postgis-users] (no subject)

Henri De Feraudy feraudyh at yahoo.com
Thu Sep 16 10:13:50 PDT 2010

Thankyou Kevin, 
  I suppose that the oid of a table is what 'table2'::regclass returns.
  I wonder what the parameterless version of Populate_Geometry_Columns does, I 
can't see its description in the documentation.

From: Kevin Neufeld <kneufeld at refractions.net>
To: postgis-users at postgis.refractions.net
Sent: Thu, September 16, 2010 5:53:04 PM
Subject: Re: [postgis-users] (no subject)

It's true that if you create a table in this manner, the geometry column of 
table2 won't be registered with the geometry column metadata information listed 
in geometry_columns (which is often needed by third-party applications).  
Further, the table2 table will be missing the usual 3 sanity check constraints 
usually placed on a geometry column.  In other words, after table2 has been 
created, you could theoretically update the geometry column to contain mixed 
geometry types, projections, or dimensions - a sure source of bugs in any 

Populate_Geometry_Columns() addresses these issues.

SELECT Populate_Geometry_Columns('table2'::regclass);


On 9/16/2010 8:11 AM, Henri De Feraudy wrote: 
The SQL Cookbook recommends the following SQL code to copy a table's structure 
from table1 to table2:
>create table table2 as select * from table1 where 1=0;
>What's great about this is that it obviates the need to know the structure of 
>But what if table1 has a geometry column?
>As geometry column existence is recorded in some other tables it doesnt look as 
>if the above trick is doing enough.
>What's your suggestion?
> _______________________________________________ postgis-users mailing list 
>postgis-users at postgis.refractions.net 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20100916/cef44949/attachment.html>

More information about the postgis-users mailing list