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

[Obe, Regina]

Let us not forget as rare as the use case is of having mixed srids in a
table I can think of some.  What is the proposition for dealing with
those?

Will we have one that takes no srid and or will we just not allow that
anymore?
The datatype declaration can exclude the srid parameter which would
allow for any kind of geometry?

I also recall having this same discussion before 8.3 came out, although
it was less clear how the added parameters to datatype would help us
although I recall Paul saying "cool" or something like that so he really
must be asleep or I must be dreaming :).

The only problem with analyze is I fail to see how this helps with
views.  The main PITA I have with the geometry_columns thing is that I
have to manually register my views or as Kevin says - write some hack to
query the system tables to derive the SRID of my views.


Regarding this
>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.

If we go with the extra param thing - seems setsrid just should not be
legal.  You would accomplish the same trick with an 

ALTER TABLE  column... USING (ST_SETSRID(...))

just like when you convert from one data type to another.  

Just my two cents,
Regina 

-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Paul
Ramsey
Sent: Thursday, June 05, 2008 9:13 AM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Re: [postgis-users] create tables smarter

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.h
tml
> and
>
http://postgis.refractions.net/pipermail/postgis-users/2008-May/019886.h
tml
> 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.
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel
-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.