From: Kevin Neufeld Date: Thu, 16 Sep 2010 08:53:04 -0700 Subject: [postgis-users] (no subject) In-Reply-To: <764714.61449.qm@web110801.mail.gq1.yahoo.com> References: <764714.61449.qm@web110801.mail.gq1.yahoo.com> Message-ID: <4C923D60.3050403@refractions.net> 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 application. Populate_Geometry_Columns() addresses these issues. http://postgis.refractions.net/docs/Populate_Geometry_Columns.html SELECT Populate_Geometry_Columns('table2'::regclass); Cheers, Kevin 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 table1. > > 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? > Henri > > > _______________________________________________ > postgis-users mailing list > postgis-users at postgis.refractions.net > http://postgis.refractions.net/mailman/listinfo/postgis-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: