[postgis-devel] Re: [postgis-users] create tables smarter

[Paul Ramsey]

We should think pretty hard before doing this. As Tom noted, this is
not much different than just moving AddGeometryColumns into the CREATE
TABLE statement, in terms of information required. We also have the
problem of what to DO with geometry that is defined WITHOUT these
options. If I don't miss by guess, geometry created with a CREATE
TABLE AS SELECT... will be in this category, for example.

What happens when someone runs a UPDATE table SET
geom=setsrid(geom,400) ? Will that be (a) allowed and (b) reflected in
the metadata after it is done? If not then the usefulness of the
change begins to fall off precipitately.

I wonder if the utility process running inside ANALYZE might not be
the more helpful solution in the end.

P.


On Thu, Jun 5, 2008 at 5:53 AM, Mark Cave-Ayland
<mark.cave-ayland at siriusit.co.uk> wrote:

> Given the massive re-working of the codebase (see
> http://postgis.refractions.net/pipermail/postgis-devel/2008-May/003010.html
> and
> http://postgis.refractions.net/pipermail/postgis-users/2008-May/019886.html
> for a catch-up) I'm happy to work on this in SVN trunk when we decide on the
> final layout. The hardest bit will be trying to keep the maintenance of both
> the new code for 8.3+ and the existing code relatively sane.