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.
Henri
________________________________
From: Kevin Neufeld <[email protected]>
To: [email protected]
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
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
>[email protected]
>http://postgis.refractions.net/mailman/listinfo/postgis-users
>_______________________________________________
postgis-users mailing list
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users
