#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

My gut feeling says we should keep AddGeometryColumn, populate etc. more
or less as is so they still do the add constraint thing and register into
geometry_columns or a new table called

geometry_columns_legacy;

So here is my thought for merging the old with the new world.

st_geometry_columns -- a view parallel in concept to geography_columns
that just inspects the catalogs -- perhaps just leaves out geometry
columns with no typmod info (or includes them I guess marking them as just
geometry). this is a true SQL/MM implementation.

geometry_columns -- a view that unions st_geometry_columns (except for
those just marked as geometry) with geometry_columns_legacy. So old
applications can continue to work as they did before.

The populate, addgeometrycolumns etc. will just populate
geometry_columns_legacy. We will expect all people expecting the new
behavior to use the typmod behavior for creating geometries. It would
also only add constraints to columns that don't use typmod construction.

Any thoughts / issues people see?

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)

#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

My gut feeling says we should keep AddGeometryColumn, populate etc. more
or less as is so they still do the add constraint thing and register into
geometry_columns or a new table called

geometry_columns_legacy;

So here is my thought for merging the old with the new world.

st_geometry_columns -- a view parallel in concept to geography_columns
that just inspects the catalogs -- perhaps just leaves out geometry
columns with no typmod info (or includes them I guess marking them as just
geometry). this is a true SQL/MM implementation.

geometry_columns -- a view that unions st_geometry_columns (except for
those just marked as geometry) with geometry_columns_legacy. So old
applications can continue to work as they did before.

The populate, addgeometrycolumns etc. will just populate
geometry_columns_legacy. We will expect all people expecting the new
behavior to use the typmod behavior for creating geometries. It would
also only add constraints to columns that don't use typmod construction.

Any thoughts / issues people see?

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

I was hoping to just do it the same way geography does. A simple
geometry_columns view on the system tables. For backwards compatibility,
the Add/Remove utility functions can be simplified down to wrappers on
ALTER TABLE ADD COLUMN, etc.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)

#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

My gut feeling says we should keep AddGeometryColumn, populate etc. more
or less as is so they still do the add constraint thing and register into
geometry_columns or a new table called

geometry_columns_legacy;

So here is my thought for merging the old with the new world.

st_geometry_columns -- a view parallel in concept to geography_columns
that just inspects the catalogs -- perhaps just leaves out geometry
columns with no typmod info (or includes them I guess marking them as just
geometry). this is a true SQL/MM implementation.

geometry_columns -- a view that unions st_geometry_columns (except for
those just marked as geometry) with geometry_columns_legacy. So old
applications can continue to work as they did before.

The populate, addgeometrycolumns etc. will just populate
geometry_columns_legacy. We will expect all people expecting the new
behavior to use the typmod behavior for creating geometries. It would
also only add constraints to columns that don't use typmod construction.

Any thoughts / issues people see?

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

I was hoping to just do it the same way geography does. A simple
geometry_columns view on the system tables. For backwards compatibility,
the Add/Remove utility functions can be simplified down to wrappers on
ALTER TABLE ADD COLUMN, etc.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

Normally I'd be the first to say down with the past except in this case
I'm not convinced the new way is always superior to the past. Then again I
think about my frustrating arguments with Josh Berkus how he thinks people
should just use text and put size checks on their fields. Feels funny
being on the other side of the argument.

If we are going to make the old functions wrappers around ALTER TABLE,
what am I going to do about my case when I want POLYGONS/MULTIPOLYGONS in
the same table because in many cases, there isn't any reason to treat them
separately. Also the case of inheritance. Now my work flow is so much
more complicated. Before I would just add it as a MULTIPOLYGON and
manually relax the type constraint to allow POLYGONS. Also the case with
the inheritance thing I talked about.

I know Paul is thinking "Why is it always about you, Regina?". Cause I'm
the first use case I can think of :).

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)

#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

My gut feeling says we should keep AddGeometryColumn, populate etc. more
or less as is so they still do the add constraint thing and register into
geometry_columns or a new table called

geometry_columns_legacy;

So here is my thought for merging the old with the new world.

st_geometry_columns -- a view parallel in concept to geography_columns
that just inspects the catalogs -- perhaps just leaves out geometry
columns with no typmod info (or includes them I guess marking them as just
geometry). this is a true SQL/MM implementation.

geometry_columns -- a view that unions st_geometry_columns (except for
those just marked as geometry) with geometry_columns_legacy. So old
applications can continue to work as they did before.

The populate, addgeometrycolumns etc. will just populate
geometry_columns_legacy. We will expect all people expecting the new
behavior to use the typmod behavior for creating geometries. It would
also only add constraints to columns that don't use typmod construction.

Any thoughts / issues people see?

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

I was hoping to just do it the same way geography does. A simple
geometry_columns view on the system tables. For backwards compatibility,
the Add/Remove utility functions can be simplified down to wrappers on
ALTER TABLE ADD COLUMN, etc.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

Normally I'd be the first to say down with the past except in this case
I'm not convinced the new way is always superior to the past. Then again I
think about my frustrating arguments with Josh Berkus how he thinks people
should just use text and put size checks on their fields. Feels funny
being on the other side of the argument.

If we are going to make the old functions wrappers around ALTER TABLE,
what am I going to do about my case when I want POLYGONS/MULTIPOLYGONS in
the same table because in many cases, there isn't any reason to treat them
separately. Also the case of inheritance. Now my work flow is so much
more complicated. Before I would just add it as a MULTIPOLYGON and
manually relax the type constraint to allow POLYGONS. Also the case with
the inheritance thing I talked about.

I know Paul is thinking "Why is it always about you, Regina?". Cause I'm
the first use case I can think of :).

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

Oh I forgot about the issue of all those people with existing tables --
with your model we would have to force them to alter all their existing
tables to typmod explicit types if they wanted to still use
geometry_columns. I suspect that would take a long time with large tables.
Not to mention we would probably have to create a script to do that to
make it less painful.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)

#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

My gut feeling says we should keep AddGeometryColumn, populate etc. more
or less as is so they still do the add constraint thing and register into
geometry_columns or a new table called

geometry_columns_legacy;

So here is my thought for merging the old with the new world.

st_geometry_columns -- a view parallel in concept to geography_columns
that just inspects the catalogs -- perhaps just leaves out geometry
columns with no typmod info (or includes them I guess marking them as just
geometry). this is a true SQL/MM implementation.

geometry_columns -- a view that unions st_geometry_columns (except for
those just marked as geometry) with geometry_columns_legacy. So old
applications can continue to work as they did before.

The populate, addgeometrycolumns etc. will just populate
geometry_columns_legacy. We will expect all people expecting the new
behavior to use the typmod behavior for creating geometries. It would
also only add constraints to columns that don't use typmod construction.

Any thoughts / issues people see?

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

I was hoping to just do it the same way geography does. A simple
geometry_columns view on the system tables. For backwards compatibility,
the Add/Remove utility functions can be simplified down to wrappers on
ALTER TABLE ADD COLUMN, etc.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

Normally I'd be the first to say down with the past except in this case
I'm not convinced the new way is always superior to the past. Then again I
think about my frustrating arguments with Josh Berkus how he thinks people
should just use text and put size checks on their fields. Feels funny
being on the other side of the argument.

If we are going to make the old functions wrappers around ALTER TABLE,
what am I going to do about my case when I want POLYGONS/MULTIPOLYGONS in
the same table because in many cases, there isn't any reason to treat them
separately. Also the case of inheritance. Now my work flow is so much
more complicated. Before I would just add it as a MULTIPOLYGON and
manually relax the type constraint to allow POLYGONS. Also the case with
the inheritance thing I talked about.

I know Paul is thinking "Why is it always about you, Regina?". Cause I'm
the first use case I can think of :).

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

Oh I forgot about the issue of all those people with existing tables --
with your model we would have to force them to alter all their existing
tables to typmod explicit types if they wanted to still use
geometry_columns. I suspect that would take a long time with large tables.
Not to mention we would probably have to create a script to do that to
make it less painful.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

Do we want a painful migration or to be stuck with an ugly hack forever?

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)

#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

My gut feeling says we should keep AddGeometryColumn, populate etc. more
or less as is so they still do the add constraint thing and register into
geometry_columns or a new table called

geometry_columns_legacy;

So here is my thought for merging the old with the new world.

st_geometry_columns -- a view parallel in concept to geography_columns
that just inspects the catalogs -- perhaps just leaves out geometry
columns with no typmod info (or includes them I guess marking them as just
geometry). this is a true SQL/MM implementation.

geometry_columns -- a view that unions st_geometry_columns (except for
those just marked as geometry) with geometry_columns_legacy. So old
applications can continue to work as they did before.

The populate, addgeometrycolumns etc. will just populate
geometry_columns_legacy. We will expect all people expecting the new
behavior to use the typmod behavior for creating geometries. It would
also only add constraints to columns that don't use typmod construction.

Any thoughts / issues people see?

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

I was hoping to just do it the same way geography does. A simple
geometry_columns view on the system tables. For backwards compatibility,
the Add/Remove utility functions can be simplified down to wrappers on
ALTER TABLE ADD COLUMN, etc.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

Normally I'd be the first to say down with the past except in this case
I'm not convinced the new way is always superior to the past. Then again I
think about my frustrating arguments with Josh Berkus how he thinks people
should just use text and put size checks on their fields. Feels funny
being on the other side of the argument.

If we are going to make the old functions wrappers around ALTER TABLE,
what am I going to do about my case when I want POLYGONS/MULTIPOLYGONS in
the same table because in many cases, there isn't any reason to treat them
separately. Also the case of inheritance. Now my work flow is so much
more complicated. Before I would just add it as a MULTIPOLYGON and
manually relax the type constraint to allow POLYGONS. Also the case with
the inheritance thing I talked about.

I know Paul is thinking "Why is it always about you, Regina?". Cause I'm
the first use case I can think of :).

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

Oh I forgot about the issue of all those people with existing tables --
with your model we would have to force them to alter all their existing
tables to typmod explicit types if they wanted to still use
geometry_columns. I suspect that would take a long time with large tables.
Not to mention we would probably have to create a script to do that to
make it less painful.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

Do we want a painful migration or to be stuck with an ugly hack forever?

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

ugly hack. ugly hack. ugly hack. Ugly is in the eye of the beholder, but
pain is felt by everyone :)
Besides that's why I'm going for an ST_geometry_columns. That is what
SQL/MM says it should be called. So let's call the pure solution that and
then perhaps one day we can deprecate geometry_columns and then remove it.

I also don't want an old thing AddGeometryColumns camoflaging a new way.
If we are going to push people to do it the easy way CREATE TABLE ...
geometry(POINT,..);

Why confuse them with having the old do the new. At some point we might
want to deprecate AddgeometryColumns so its best people not rely on it to
do a new thing.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)

#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

My gut feeling says we should keep AddGeometryColumn, populate etc. more
or less as is so they still do the add constraint thing and register into
geometry_columns or a new table called

geometry_columns_legacy;

So here is my thought for merging the old with the new world.

st_geometry_columns -- a view parallel in concept to geography_columns
that just inspects the catalogs -- perhaps just leaves out geometry
columns with no typmod info (or includes them I guess marking them as just
geometry). this is a true SQL/MM implementation.

geometry_columns -- a view that unions st_geometry_columns (except for
those just marked as geometry) with geometry_columns_legacy. So old
applications can continue to work as they did before.

The populate, addgeometrycolumns etc. will just populate
geometry_columns_legacy. We will expect all people expecting the new
behavior to use the typmod behavior for creating geometries. It would
also only add constraints to columns that don't use typmod construction.

Any thoughts / issues people see?

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

I was hoping to just do it the same way geography does. A simple
geometry_columns view on the system tables. For backwards compatibility,
the Add/Remove utility functions can be simplified down to wrappers on
ALTER TABLE ADD COLUMN, etc.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

Normally I'd be the first to say down with the past except in this case
I'm not convinced the new way is always superior to the past. Then again I
think about my frustrating arguments with Josh Berkus how he thinks people
should just use text and put size checks on their fields. Feels funny
being on the other side of the argument.

If we are going to make the old functions wrappers around ALTER TABLE,
what am I going to do about my case when I want POLYGONS/MULTIPOLYGONS in
the same table because in many cases, there isn't any reason to treat them
separately. Also the case of inheritance. Now my work flow is so much
more complicated. Before I would just add it as a MULTIPOLYGON and
manually relax the type constraint to allow POLYGONS. Also the case with
the inheritance thing I talked about.

I know Paul is thinking "Why is it always about you, Regina?". Cause I'm
the first use case I can think of :).

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

Oh I forgot about the issue of all those people with existing tables --
with your model we would have to force them to alter all their existing
tables to typmod explicit types if they wanted to still use
geometry_columns. I suspect that would take a long time with large tables.
Not to mention we would probably have to create a script to do that to
make it less painful.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

Do we want a painful migration or to be stuck with an ugly hack forever?

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

ugly hack. ugly hack. ugly hack. Ugly is in the eye of the beholder, but
pain is felt by everyone :)
Besides that's why I'm going for an ST_geometry_columns. That is what
SQL/MM says it should be called. So let's call the pure solution that and
then perhaps one day we can deprecate geometry_columns and then remove it.

I also don't want an old thing AddGeometryColumns camoflaging a new way.
If we are going to push people to do it the easy way CREATE TABLE ...
geometry(POINT,..);

Why confuse them with having the old do the new. At some point we might
want to deprecate AddgeometryColumns so its best people not rely on it to
do a new thing.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

How about we change geometry_columns to old_geometry_columns.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)

#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

My gut feeling says we should keep AddGeometryColumn, populate etc. more
or less as is so they still do the add constraint thing and register into
geometry_columns or a new table called

geometry_columns_legacy;

So here is my thought for merging the old with the new world.

st_geometry_columns -- a view parallel in concept to geography_columns
that just inspects the catalogs -- perhaps just leaves out geometry
columns with no typmod info (or includes them I guess marking them as just
geometry). this is a true SQL/MM implementation.

geometry_columns -- a view that unions st_geometry_columns (except for
those just marked as geometry) with geometry_columns_legacy. So old
applications can continue to work as they did before.

The populate, addgeometrycolumns etc. will just populate
geometry_columns_legacy. We will expect all people expecting the new
behavior to use the typmod behavior for creating geometries. It would
also only add constraints to columns that don't use typmod construction.

Any thoughts / issues people see?

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

I was hoping to just do it the same way geography does. A simple
geometry_columns view on the system tables. For backwards compatibility,
the Add/Remove utility functions can be simplified down to wrappers on
ALTER TABLE ADD COLUMN, etc.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

Normally I'd be the first to say down with the past except in this case
I'm not convinced the new way is always superior to the past. Then again I
think about my frustrating arguments with Josh Berkus how he thinks people
should just use text and put size checks on their fields. Feels funny
being on the other side of the argument.

If we are going to make the old functions wrappers around ALTER TABLE,
what am I going to do about my case when I want POLYGONS/MULTIPOLYGONS in
the same table because in many cases, there isn't any reason to treat them
separately. Also the case of inheritance. Now my work flow is so much
more complicated. Before I would just add it as a MULTIPOLYGON and
manually relax the type constraint to allow POLYGONS. Also the case with
the inheritance thing I talked about.

I know Paul is thinking "Why is it always about you, Regina?". Cause I'm
the first use case I can think of :).

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

Oh I forgot about the issue of all those people with existing tables --
with your model we would have to force them to alter all their existing
tables to typmod explicit types if they wanted to still use
geometry_columns. I suspect that would take a long time with large tables.
Not to mention we would probably have to create a script to do that to
make it less painful.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

Do we want a painful migration or to be stuck with an ugly hack forever?

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

ugly hack. ugly hack. ugly hack. Ugly is in the eye of the beholder, but
pain is felt by everyone :)
Besides that's why I'm going for an ST_geometry_columns. That is what
SQL/MM says it should be called. So let's call the pure solution that and
then perhaps one day we can deprecate geometry_columns and then remove it.

I also don't want an old thing AddGeometryColumns camoflaging a new way.
If we are going to push people to do it the easy way CREATE TABLE ...
geometry(POINT,..);

Why confuse them with having the old do the new. At some point we might
want to deprecate AddgeometryColumns so its best people not rely on it to
do a new thing.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

How about we change geometry_columns to old_geometry_columns.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

You mean all the addgeometry stuff works against old_geometry_columns
(instead of geometry_columns_legacy). I'm indifferent about the name.

Just that geometry_columns be a view and should be a fuse of old and new.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)

#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

My gut feeling says we should keep AddGeometryColumn, populate etc. more
or less as is so they still do the add constraint thing and register into
geometry_columns or a new table called

geometry_columns_legacy;

So here is my thought for merging the old with the new world.

st_geometry_columns -- a view parallel in concept to geography_columns
that just inspects the catalogs -- perhaps just leaves out geometry
columns with no typmod info (or includes them I guess marking them as just
geometry). this is a true SQL/MM implementation.

geometry_columns -- a view that unions st_geometry_columns (except for
those just marked as geometry) with geometry_columns_legacy. So old
applications can continue to work as they did before.

The populate, addgeometrycolumns etc. will just populate
geometry_columns_legacy. We will expect all people expecting the new
behavior to use the typmod behavior for creating geometries. It would
also only add constraints to columns that don't use typmod construction.

Any thoughts / issues people see?

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

I was hoping to just do it the same way geography does. A simple
geometry_columns view on the system tables. For backwards compatibility,
the Add/Remove utility functions can be simplified down to wrappers on
ALTER TABLE ADD COLUMN, etc.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

Normally I'd be the first to say down with the past except in this case
I'm not convinced the new way is always superior to the past. Then again I
think about my frustrating arguments with Josh Berkus how he thinks people
should just use text and put size checks on their fields. Feels funny
being on the other side of the argument.

If we are going to make the old functions wrappers around ALTER TABLE,
what am I going to do about my case when I want POLYGONS/MULTIPOLYGONS in
the same table because in many cases, there isn't any reason to treat them
separately. Also the case of inheritance. Now my work flow is so much
more complicated. Before I would just add it as a MULTIPOLYGON and
manually relax the type constraint to allow POLYGONS. Also the case with
the inheritance thing I talked about.

I know Paul is thinking "Why is it always about you, Regina?". Cause I'm
the first use case I can think of :).

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

Oh I forgot about the issue of all those people with existing tables --
with your model we would have to force them to alter all their existing
tables to typmod explicit types if they wanted to still use
geometry_columns. I suspect that would take a long time with large tables.
Not to mention we would probably have to create a script to do that to
make it less painful.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

Do we want a painful migration or to be stuck with an ugly hack forever?

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

ugly hack. ugly hack. ugly hack. Ugly is in the eye of the beholder, but
pain is felt by everyone :)
Besides that's why I'm going for an ST_geometry_columns. That is what
SQL/MM says it should be called. So let's call the pure solution that and
then perhaps one day we can deprecate geometry_columns and then remove it.

I also don't want an old thing AddGeometryColumns camoflaging a new way.
If we are going to push people to do it the easy way CREATE TABLE ...
geometry(POINT,..);

Why confuse them with having the old do the new. At some point we might
want to deprecate AddgeometryColumns so its best people not rely on it to
do a new thing.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

How about we change geometry_columns to old_geometry_columns.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

You mean all the addgeometry stuff works against old_geometry_columns
(instead of geometry_columns_legacy). I'm indifferent about the name.

Just that geometry_columns be a view and should be a fuse of old and new.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

How do you think the view can fuse the old and new? It'll necessarily find
all the non-typmod'ed columns in the system tables along with the
typmodded ones...

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)

#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

My gut feeling says we should keep AddGeometryColumn, populate etc. more
or less as is so they still do the add constraint thing and register into
geometry_columns or a new table called

geometry_columns_legacy;

So here is my thought for merging the old with the new world.

st_geometry_columns -- a view parallel in concept to geography_columns
that just inspects the catalogs -- perhaps just leaves out geometry
columns with no typmod info (or includes them I guess marking them as just
geometry). this is a true SQL/MM implementation.

geometry_columns -- a view that unions st_geometry_columns (except for
those just marked as geometry) with geometry_columns_legacy. So old
applications can continue to work as they did before.

The populate, addgeometrycolumns etc. will just populate
geometry_columns_legacy. We will expect all people expecting the new
behavior to use the typmod behavior for creating geometries. It would
also only add constraints to columns that don't use typmod construction.

Any thoughts / issues people see?

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

I was hoping to just do it the same way geography does. A simple
geometry_columns view on the system tables. For backwards compatibility,
the Add/Remove utility functions can be simplified down to wrappers on
ALTER TABLE ADD COLUMN, etc.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

Normally I'd be the first to say down with the past except in this case
I'm not convinced the new way is always superior to the past. Then again I
think about my frustrating arguments with Josh Berkus how he thinks people
should just use text and put size checks on their fields. Feels funny
being on the other side of the argument.

If we are going to make the old functions wrappers around ALTER TABLE,
what am I going to do about my case when I want POLYGONS/MULTIPOLYGONS in
the same table because in many cases, there isn't any reason to treat them
separately. Also the case of inheritance. Now my work flow is so much
more complicated. Before I would just add it as a MULTIPOLYGON and
manually relax the type constraint to allow POLYGONS. Also the case with
the inheritance thing I talked about.

I know Paul is thinking "Why is it always about you, Regina?". Cause I'm
the first use case I can think of :).

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

Oh I forgot about the issue of all those people with existing tables --
with your model we would have to force them to alter all their existing
tables to typmod explicit types if they wanted to still use
geometry_columns. I suspect that would take a long time with large tables.
Not to mention we would probably have to create a script to do that to
make it less painful.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

Do we want a painful migration or to be stuck with an ugly hack forever?

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

ugly hack. ugly hack. ugly hack. Ugly is in the eye of the beholder, but
pain is felt by everyone :)
Besides that's why I'm going for an ST_geometry_columns. That is what
SQL/MM says it should be called. So let's call the pure solution that and
then perhaps one day we can deprecate geometry_columns and then remove it.

I also don't want an old thing AddGeometryColumns camoflaging a new way.
If we are going to push people to do it the easy way CREATE TABLE ...
geometry(POINT,..);

Why confuse them with having the old do the new. At some point we might
want to deprecate AddgeometryColumns so its best people not rely on it to
do a new thing.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

How about we change geometry_columns to old_geometry_columns.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

You mean all the addgeometry stuff works against old_geometry_columns
(instead of geometry_columns_legacy). I'm indifferent about the name.

Just that geometry_columns be a view and should be a fuse of old and new.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

How do you think the view can fuse the old and new? It'll necessarily find
all the non-typmod'ed columns in the system tables along with the
typmodded ones...

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

SELECT all geometry columns with a geometry type (not like geometry)
UNION ALL
geometry_columns_old

How about this Paul, you go do your typmod thing since that's a known we
want and we have no differences in opinion how that should be done.

I'll do the view, the revision of all the management functions. I'll even
write the pre install script that renames peoples existing
geometry_columns should they have one and I'll submit this as a patch for
you to tear apart and do what you will with. Deal?

BTW: we also need to change the loader. I think as a clean beginning it
should check versions of PostGIS and for version of PostGIS 2.0+ it should
use the standard CREATE TABLE ...geometry(..) instead of the management
functions. Would be nice if we had a switch option to allow people to
choose the old addgeometrycolumns or new typmod behavior and default to
new behavior, but that should go in as a separate ticket I think.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)

#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

My gut feeling says we should keep AddGeometryColumn, populate etc. more
or less as is so they still do the add constraint thing and register into
geometry_columns or a new table called

geometry_columns_legacy;

So here is my thought for merging the old with the new world.

st_geometry_columns -- a view parallel in concept to geography_columns
that just inspects the catalogs -- perhaps just leaves out geometry
columns with no typmod info (or includes them I guess marking them as just
geometry). this is a true SQL/MM implementation.

geometry_columns -- a view that unions st_geometry_columns (except for
those just marked as geometry) with geometry_columns_legacy. So old
applications can continue to work as they did before.

The populate, addgeometrycolumns etc. will just populate
geometry_columns_legacy. We will expect all people expecting the new
behavior to use the typmod behavior for creating geometries. It would
also only add constraints to columns that don't use typmod construction.

Any thoughts / issues people see?

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

I was hoping to just do it the same way geography does. A simple
geometry_columns view on the system tables. For backwards compatibility,
the Add/Remove utility functions can be simplified down to wrappers on
ALTER TABLE ADD COLUMN, etc.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

Normally I'd be the first to say down with the past except in this case
I'm not convinced the new way is always superior to the past. Then again I
think about my frustrating arguments with Josh Berkus how he thinks people
should just use text and put size checks on their fields. Feels funny
being on the other side of the argument.

If we are going to make the old functions wrappers around ALTER TABLE,
what am I going to do about my case when I want POLYGONS/MULTIPOLYGONS in
the same table because in many cases, there isn't any reason to treat them
separately. Also the case of inheritance. Now my work flow is so much
more complicated. Before I would just add it as a MULTIPOLYGON and
manually relax the type constraint to allow POLYGONS. Also the case with
the inheritance thing I talked about.

I know Paul is thinking "Why is it always about you, Regina?". Cause I'm
the first use case I can think of :).

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

Oh I forgot about the issue of all those people with existing tables --
with your model we would have to force them to alter all their existing
tables to typmod explicit types if they wanted to still use
geometry_columns. I suspect that would take a long time with large tables.
Not to mention we would probably have to create a script to do that to
make it less painful.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

Do we want a painful migration or to be stuck with an ugly hack forever?

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

ugly hack. ugly hack. ugly hack. Ugly is in the eye of the beholder, but
pain is felt by everyone :)
Besides that's why I'm going for an ST_geometry_columns. That is what
SQL/MM says it should be called. So let's call the pure solution that and
then perhaps one day we can deprecate geometry_columns and then remove it.

I also don't want an old thing AddGeometryColumns camoflaging a new way.
If we are going to push people to do it the easy way CREATE TABLE ...
geometry(POINT,..);

Why confuse them with having the old do the new. At some point we might
want to deprecate AddgeometryColumns so its best people not rely on it to
do a new thing.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

How about we change geometry_columns to old_geometry_columns.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

You mean all the addgeometry stuff works against old_geometry_columns
(instead of geometry_columns_legacy). I'm indifferent about the name.

Just that geometry_columns be a view and should be a fuse of old and new.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

How do you think the view can fuse the old and new? It'll necessarily find
all the non-typmod'ed columns in the system tables along with the
typmodded ones...

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

SELECT all geometry columns with a geometry type (not like geometry)
UNION ALL
geometry_columns_old

How about this Paul, you go do your typmod thing since that's a known we
want and we have no differences in opinion how that should be done.

I'll do the view, the revision of all the management functions. I'll even
write the pre install script that renames peoples existing
geometry_columns should they have one and I'll submit this as a patch for
you to tear apart and do what you will with. Deal?

BTW: we also need to change the loader. I think as a clean beginning it
should check versions of PostGIS and for version of PostGIS 2.0+ it should
use the standard CREATE TABLE ...geometry(..) instead of the management
functions. Would be nice if we had a switch option to allow people to
choose the old addgeometrycolumns or new typmod behavior and default to
new behavior, but that should go in as a separate ticket I think.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by mcayland):

Gosh - this all sounds really really horrible and likely to come back and
bite us later. Hard.

It sounds as if we just need a generic "GEOMETRY" type we can put in the
typmod that will allow any type of geometry within the column. If you're
really foolish enough to be mixing geometry types in a single column then
you're definitely not adhering to the OGC standard, so I don't see lack of
adherence to the OGC specification being an issue here.

Oh and talking about OGC spec compliance - even if we do get rid of the
geometry_columns table, we still need to keep the AddGeometryColumn() and
DropGeometryColumn() functions, even if they don't actually end up doing
anything.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)

#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

My gut feeling says we should keep AddGeometryColumn, populate etc. more
or less as is so they still do the add constraint thing and register into
geometry_columns or a new table called

geometry_columns_legacy;

So here is my thought for merging the old with the new world.

st_geometry_columns -- a view parallel in concept to geography_columns
that just inspects the catalogs -- perhaps just leaves out geometry
columns with no typmod info (or includes them I guess marking them as just
geometry). this is a true SQL/MM implementation.

geometry_columns -- a view that unions st_geometry_columns (except for
those just marked as geometry) with geometry_columns_legacy. So old
applications can continue to work as they did before.

The populate, addgeometrycolumns etc. will just populate
geometry_columns_legacy. We will expect all people expecting the new
behavior to use the typmod behavior for creating geometries. It would
also only add constraints to columns that don't use typmod construction.

Any thoughts / issues people see?

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

I was hoping to just do it the same way geography does. A simple
geometry_columns view on the system tables. For backwards compatibility,
the Add/Remove utility functions can be simplified down to wrappers on
ALTER TABLE ADD COLUMN, etc.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

Normally I'd be the first to say down with the past except in this case
I'm not convinced the new way is always superior to the past. Then again I
think about my frustrating arguments with Josh Berkus how he thinks people
should just use text and put size checks on their fields. Feels funny
being on the other side of the argument.

If we are going to make the old functions wrappers around ALTER TABLE,
what am I going to do about my case when I want POLYGONS/MULTIPOLYGONS in
the same table because in many cases, there isn't any reason to treat them
separately. Also the case of inheritance. Now my work flow is so much
more complicated. Before I would just add it as a MULTIPOLYGON and
manually relax the type constraint to allow POLYGONS. Also the case with
the inheritance thing I talked about.

I know Paul is thinking "Why is it always about you, Regina?". Cause I'm
the first use case I can think of :).

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

Oh I forgot about the issue of all those people with existing tables --
with your model we would have to force them to alter all their existing
tables to typmod explicit types if they wanted to still use
geometry_columns. I suspect that would take a long time with large tables.
Not to mention we would probably have to create a script to do that to
make it less painful.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

Do we want a painful migration or to be stuck with an ugly hack forever?

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

ugly hack. ugly hack. ugly hack. Ugly is in the eye of the beholder, but
pain is felt by everyone :)
Besides that's why I'm going for an ST_geometry_columns. That is what
SQL/MM says it should be called. So let's call the pure solution that and
then perhaps one day we can deprecate geometry_columns and then remove it.

I also don't want an old thing AddGeometryColumns camoflaging a new way.
If we are going to push people to do it the easy way CREATE TABLE ...
geometry(POINT,..);

Why confuse them with having the old do the new. At some point we might
want to deprecate AddgeometryColumns so its best people not rely on it to
do a new thing.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

How about we change geometry_columns to old_geometry_columns.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

You mean all the addgeometry stuff works against old_geometry_columns
(instead of geometry_columns_legacy). I'm indifferent about the name.

Just that geometry_columns be a view and should be a fuse of old and new.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

How do you think the view can fuse the old and new? It'll necessarily find
all the non-typmod'ed columns in the system tables along with the
typmodded ones...

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

SELECT all geometry columns with a geometry type (not like geometry)
UNION ALL
geometry_columns_old

How about this Paul, you go do your typmod thing since that's a known we
want and we have no differences in opinion how that should be done.

I'll do the view, the revision of all the management functions. I'll even
write the pre install script that renames peoples existing
geometry_columns should they have one and I'll submit this as a patch for
you to tear apart and do what you will with. Deal?

BTW: we also need to change the loader. I think as a clean beginning it
should check versions of PostGIS and for version of PostGIS 2.0+ it should
use the standard CREATE TABLE ...geometry(..) instead of the management
functions. Would be nice if we had a switch option to allow people to
choose the old addgeometrycolumns or new typmod behavior and default to
new behavior, but that should go in as a separate ticket I think.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by mcayland):

Gosh - this all sounds really really horrible and likely to come back and
bite us later. Hard.

It sounds as if we just need a generic "GEOMETRY" type we can put in the
typmod that will allow any type of geometry within the column. If you're
really foolish enough to be mixing geometry types in a single column then
you're definitely not adhering to the OGC standard, so I don't see lack of
adherence to the OGC specification being an issue here.

Oh and talking about OGC spec compliance - even if we do get rid of the
geometry_columns table, we still need to keep the AddGeometryColumn() and
DropGeometryColumn() functions, even if they don't actually end up doing
anything.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

Mark,

I think you missed my two main points
1) If we expect people tomove to PostGIS 2.0, there current tables built
with AddGeometryColumn should work as they did before. It would be
painful to have them alter their geometry columns to typmod. With that
said -- the postgresql catalog will be wrong for these geometries.

2) For inheritance tables -- it is not unusual and I don't think bad
practice to have each child have a separate geometry type (though it
should have the same srid and dimension). typmod simply doesn't work for
this model.

3) There are varying degrees -- e.g. I think for example Oracle doesn't
mind POLYGON/MULTIPOLYGON coexisting. Neither do ESRI Shapefiles. When
you have a polygon in must cases it is more efficient to keep it that way
than wrapping it in a multi wrapper. typmod doesn't work for this either.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)

#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

My gut feeling says we should keep AddGeometryColumn, populate etc. more
or less as is so they still do the add constraint thing and register into
geometry_columns or a new table called

geometry_columns_legacy;

So here is my thought for merging the old with the new world.

st_geometry_columns -- a view parallel in concept to geography_columns
that just inspects the catalogs -- perhaps just leaves out geometry
columns with no typmod info (or includes them I guess marking them as just
geometry). this is a true SQL/MM implementation.

geometry_columns -- a view that unions st_geometry_columns (except for
those just marked as geometry) with geometry_columns_legacy. So old
applications can continue to work as they did before.

The populate, addgeometrycolumns etc. will just populate
geometry_columns_legacy. We will expect all people expecting the new
behavior to use the typmod behavior for creating geometries. It would
also only add constraints to columns that don't use typmod construction.

Any thoughts / issues people see?

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

I was hoping to just do it the same way geography does. A simple
geometry_columns view on the system tables. For backwards compatibility,
the Add/Remove utility functions can be simplified down to wrappers on
ALTER TABLE ADD COLUMN, etc.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

Normally I'd be the first to say down with the past except in this case
I'm not convinced the new way is always superior to the past. Then again I
think about my frustrating arguments with Josh Berkus how he thinks people
should just use text and put size checks on their fields. Feels funny
being on the other side of the argument.

If we are going to make the old functions wrappers around ALTER TABLE,
what am I going to do about my case when I want POLYGONS/MULTIPOLYGONS in
the same table because in many cases, there isn't any reason to treat them
separately. Also the case of inheritance. Now my work flow is so much
more complicated. Before I would just add it as a MULTIPOLYGON and
manually relax the type constraint to allow POLYGONS. Also the case with
the inheritance thing I talked about.

I know Paul is thinking "Why is it always about you, Regina?". Cause I'm
the first use case I can think of :).

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

Oh I forgot about the issue of all those people with existing tables --
with your model we would have to force them to alter all their existing
tables to typmod explicit types if they wanted to still use
geometry_columns. I suspect that would take a long time with large tables.
Not to mention we would probably have to create a script to do that to
make it less painful.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

Do we want a painful migration or to be stuck with an ugly hack forever?

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

ugly hack. ugly hack. ugly hack. Ugly is in the eye of the beholder, but
pain is felt by everyone :)
Besides that's why I'm going for an ST_geometry_columns. That is what
SQL/MM says it should be called. So let's call the pure solution that and
then perhaps one day we can deprecate geometry_columns and then remove it.

I also don't want an old thing AddGeometryColumns camoflaging a new way.
If we are going to push people to do it the easy way CREATE TABLE ...
geometry(POINT,..);

Why confuse them with having the old do the new. At some point we might
want to deprecate AddgeometryColumns so its best people not rely on it to
do a new thing.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

How about we change geometry_columns to old_geometry_columns.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

You mean all the addgeometry stuff works against old_geometry_columns
(instead of geometry_columns_legacy). I'm indifferent about the name.

Just that geometry_columns be a view and should be a fuse of old and new.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

How do you think the view can fuse the old and new? It'll necessarily find
all the non-typmod'ed columns in the system tables along with the
typmodded ones...

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

SELECT all geometry columns with a geometry type (not like geometry)
UNION ALL
geometry_columns_old

How about this Paul, you go do your typmod thing since that's a known we
want and we have no differences in opinion how that should be done.

I'll do the view, the revision of all the management functions. I'll even
write the pre install script that renames peoples existing
geometry_columns should they have one and I'll submit this as a patch for
you to tear apart and do what you will with. Deal?

BTW: we also need to change the loader. I think as a clean beginning it
should check versions of PostGIS and for version of PostGIS 2.0+ it should
use the standard CREATE TABLE ...geometry(..) instead of the management
functions. Would be nice if we had a switch option to allow people to
choose the old addgeometrycolumns or new typmod behavior and default to
new behavior, but that should go in as a separate ticket I think.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by mcayland):

Gosh - this all sounds really really horrible and likely to come back and
bite us later. Hard.

It sounds as if we just need a generic "GEOMETRY" type we can put in the
typmod that will allow any type of geometry within the column. If you're
really foolish enough to be mixing geometry types in a single column then
you're definitely not adhering to the OGC standard, so I don't see lack of
adherence to the OGC specification being an issue here.

Oh and talking about OGC spec compliance - even if we do get rid of the
geometry_columns table, we still need to keep the AddGeometryColumn() and
DropGeometryColumn() functions, even if they don't actually end up doing
anything.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

Mark,

I think you missed my two main points
1) If we expect people tomove to PostGIS 2.0, there current tables built
with AddGeometryColumn should work as they did before. It would be
painful to have them alter their geometry columns to typmod. With that
said -- the postgresql catalog will be wrong for these geometries.

2) For inheritance tables -- it is not unusual and I don't think bad
practice to have each child have a separate geometry type (though it
should have the same srid and dimension). typmod simply doesn't work for
this model.

3) There are varying degrees -- e.g. I think for example Oracle doesn't
mind POLYGON/MULTIPOLYGON coexisting. Neither do ESRI Shapefiles. When
you have a polygon in must cases it is more efficient to keep it that way
than wrapping it in a multi wrapper. typmod doesn't work for this either.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by mcayland):

In these cases, my responses would be:

1) If we expect people tomove to PostGIS 2.0, there current tables built
with AddGeometryColumn? should work as they did before. It would be
painful to have them alter their geometry columns to typmod. With that
said -- the postgresql catalog will be wrong for these geometries.

This is something that could be automated as part of an upgrade. A script
can be run to check the uniqueness of the geometry types within a table -
if they are unique then we can update the catalog to represent the correct
value, otherwise we set the typmod to be a generic GEOMETRY instead.

And also - if we're going to make people do things like a dump/reload
(which they will need with the new geometry format in 2.0) we might as
well do other horrible things as part of the upgrade.

2) For inheritance tables -- it is not unusual and I don't think bad
practice to have each child have a separate geometry type (though it
should have the same srid and dimension). typmod simply doesn't work for
this model.

Again, set the typmod to a generic GEOMETRY type but then add your own
constraints on your child tables. I would say that mixing things in this
way is an advanced level feature.

3) There are varying degrees -- e.g. I think for example Oracle doesn't
mind POLYGON/MULTIPOLYGON coexisting. Neither do ESRI Shapefiles. When you
have a polygon in must cases it is more efficient to keep it that way than
wrapping it in a multi wrapper. typmod doesn't work for this either.

This one is more tricky - if it were me, I would just use MULTIPOLYGONS
with one polygon for single shapes. When you say more efficient, what
exactly do you mean here?

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)

#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

My gut feeling says we should keep AddGeometryColumn, populate etc. more
or less as is so they still do the add constraint thing and register into
geometry_columns or a new table called

geometry_columns_legacy;

So here is my thought for merging the old with the new world.

st_geometry_columns -- a view parallel in concept to geography_columns
that just inspects the catalogs -- perhaps just leaves out geometry
columns with no typmod info (or includes them I guess marking them as just
geometry). this is a true SQL/MM implementation.

geometry_columns -- a view that unions st_geometry_columns (except for
those just marked as geometry) with geometry_columns_legacy. So old
applications can continue to work as they did before.

The populate, addgeometrycolumns etc. will just populate
geometry_columns_legacy. We will expect all people expecting the new
behavior to use the typmod behavior for creating geometries. It would
also only add constraints to columns that don't use typmod construction.

Any thoughts / issues people see?

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

I was hoping to just do it the same way geography does. A simple
geometry_columns view on the system tables. For backwards compatibility,
the Add/Remove utility functions can be simplified down to wrappers on
ALTER TABLE ADD COLUMN, etc.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

Normally I'd be the first to say down with the past except in this case
I'm not convinced the new way is always superior to the past. Then again I
think about my frustrating arguments with Josh Berkus how he thinks people
should just use text and put size checks on their fields. Feels funny
being on the other side of the argument.

If we are going to make the old functions wrappers around ALTER TABLE,
what am I going to do about my case when I want POLYGONS/MULTIPOLYGONS in
the same table because in many cases, there isn't any reason to treat them
separately. Also the case of inheritance. Now my work flow is so much
more complicated. Before I would just add it as a MULTIPOLYGON and
manually relax the type constraint to allow POLYGONS. Also the case with
the inheritance thing I talked about.

I know Paul is thinking "Why is it always about you, Regina?". Cause I'm
the first use case I can think of :).

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

Oh I forgot about the issue of all those people with existing tables --
with your model we would have to force them to alter all their existing
tables to typmod explicit types if they wanted to still use
geometry_columns. I suspect that would take a long time with large tables.
Not to mention we would probably have to create a script to do that to
make it less painful.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

Do we want a painful migration or to be stuck with an ugly hack forever?

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

ugly hack. ugly hack. ugly hack. Ugly is in the eye of the beholder, but
pain is felt by everyone :)
Besides that's why I'm going for an ST_geometry_columns. That is what
SQL/MM says it should be called. So let's call the pure solution that and
then perhaps one day we can deprecate geometry_columns and then remove it.

I also don't want an old thing AddGeometryColumns camoflaging a new way.
If we are going to push people to do it the easy way CREATE TABLE ...
geometry(POINT,..);

Why confuse them with having the old do the new. At some point we might
want to deprecate AddgeometryColumns so its best people not rely on it to
do a new thing.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

How about we change geometry_columns to old_geometry_columns.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

You mean all the addgeometry stuff works against old_geometry_columns
(instead of geometry_columns_legacy). I'm indifferent about the name.

Just that geometry_columns be a view and should be a fuse of old and new.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

How do you think the view can fuse the old and new? It'll necessarily find
all the non-typmod'ed columns in the system tables along with the
typmodded ones...

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

SELECT all geometry columns with a geometry type (not like geometry)
UNION ALL
geometry_columns_old

How about this Paul, you go do your typmod thing since that's a known we
want and we have no differences in opinion how that should be done.

I'll do the view, the revision of all the management functions. I'll even
write the pre install script that renames peoples existing
geometry_columns should they have one and I'll submit this as a patch for
you to tear apart and do what you will with. Deal?

BTW: we also need to change the loader. I think as a clean beginning it
should check versions of PostGIS and for version of PostGIS 2.0+ it should
use the standard CREATE TABLE ...geometry(..) instead of the management
functions. Would be nice if we had a switch option to allow people to
choose the old addgeometrycolumns or new typmod behavior and default to
new behavior, but that should go in as a separate ticket I think.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by mcayland):

Gosh - this all sounds really really horrible and likely to come back and
bite us later. Hard.

It sounds as if we just need a generic "GEOMETRY" type we can put in the
typmod that will allow any type of geometry within the column. If you're
really foolish enough to be mixing geometry types in a single column then
you're definitely not adhering to the OGC standard, so I don't see lack of
adherence to the OGC specification being an issue here.

Oh and talking about OGC spec compliance - even if we do get rid of the
geometry_columns table, we still need to keep the AddGeometryColumn() and
DropGeometryColumn() functions, even if they don't actually end up doing
anything.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

Mark,

I think you missed my two main points
1) If we expect people tomove to PostGIS 2.0, there current tables built
with AddGeometryColumn should work as they did before. It would be
painful to have them alter their geometry columns to typmod. With that
said -- the postgresql catalog will be wrong for these geometries.

2) For inheritance tables -- it is not unusual and I don't think bad
practice to have each child have a separate geometry type (though it
should have the same srid and dimension). typmod simply doesn't work for
this model.

3) There are varying degrees -- e.g. I think for example Oracle doesn't
mind POLYGON/MULTIPOLYGON coexisting. Neither do ESRI Shapefiles. When
you have a polygon in must cases it is more efficient to keep it that way
than wrapping it in a multi wrapper. typmod doesn't work for this either.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by mcayland):

In these cases, my responses would be:

1) If we expect people tomove to PostGIS 2.0, there current tables built
with AddGeometryColumn? should work as they did before. It would be
painful to have them alter their geometry columns to typmod. With that
said -- the postgresql catalog will be wrong for these geometries.

This is something that could be automated as part of an upgrade. A script
can be run to check the uniqueness of the geometry types within a table -
if they are unique then we can update the catalog to represent the correct
value, otherwise we set the typmod to be a generic GEOMETRY instead.

And also - if we're going to make people do things like a dump/reload
(which they will need with the new geometry format in 2.0) we might as
well do other horrible things as part of the upgrade.

2) For inheritance tables -- it is not unusual and I don't think bad
practice to have each child have a separate geometry type (though it
should have the same srid and dimension). typmod simply doesn't work for
this model.

Again, set the typmod to a generic GEOMETRY type but then add your own
constraints on your child tables. I would say that mixing things in this
way is an advanced level feature.

3) There are varying degrees -- e.g. I think for example Oracle doesn't
mind POLYGON/MULTIPOLYGON coexisting. Neither do ESRI Shapefiles. When you
have a polygon in must cases it is more efficient to keep it that way than
wrapping it in a multi wrapper. typmod doesn't work for this either.

This one is more tricky - if it were me, I would just use MULTIPOLYGONS
with one polygon for single shapes. When you say more efficient, what
exactly do you mean here?

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

1) Automation is not what I was worrying about. I was more worried about
speed.
For example converting a varchar(50) to say a varchar(1000) takes a
painful amount of time for a large table. OF course I may be over
estimating this. I think if Paul goes ahead with the typmod, I can test
with a 10 million record table converting to typmod to see just how
painful it is.

I really think we should avoid updating the catalogs directly. too much
has changed betweenn 8.4-9.1 that I wouldn't want to risk screwing it up.
Besides the PostgreSQL devs really frown on those changes.

2) Okay I can concede to that. It's a bit inconvenient than using
addgeometrycolumn but I agree it's a more advanced use case and rare at
that.

3) I think a lot of the speed issues we have addressed for this. In the
past it was significantly faster doing checks with polygons than
multipolygons even when a multipolygon had only one polygon. This is
probalby more an issue with third party tools than PostGIS.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)

#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

My gut feeling says we should keep AddGeometryColumn, populate etc. more
or less as is so they still do the add constraint thing and register into
geometry_columns or a new table called

geometry_columns_legacy;

So here is my thought for merging the old with the new world.

st_geometry_columns -- a view parallel in concept to geography_columns
that just inspects the catalogs -- perhaps just leaves out geometry
columns with no typmod info (or includes them I guess marking them as just
geometry). this is a true SQL/MM implementation.

geometry_columns -- a view that unions st_geometry_columns (except for
those just marked as geometry) with geometry_columns_legacy. So old
applications can continue to work as they did before.

The populate, addgeometrycolumns etc. will just populate
geometry_columns_legacy. We will expect all people expecting the new
behavior to use the typmod behavior for creating geometries. It would
also only add constraints to columns that don't use typmod construction.

Any thoughts / issues people see?

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

I was hoping to just do it the same way geography does. A simple
geometry_columns view on the system tables. For backwards compatibility,
the Add/Remove utility functions can be simplified down to wrappers on
ALTER TABLE ADD COLUMN, etc.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

Normally I'd be the first to say down with the past except in this case
I'm not convinced the new way is always superior to the past. Then again I
think about my frustrating arguments with Josh Berkus how he thinks people
should just use text and put size checks on their fields. Feels funny
being on the other side of the argument.

If we are going to make the old functions wrappers around ALTER TABLE,
what am I going to do about my case when I want POLYGONS/MULTIPOLYGONS in
the same table because in many cases, there isn't any reason to treat them
separately. Also the case of inheritance. Now my work flow is so much
more complicated. Before I would just add it as a MULTIPOLYGON and
manually relax the type constraint to allow POLYGONS. Also the case with
the inheritance thing I talked about.

I know Paul is thinking "Why is it always about you, Regina?". Cause I'm
the first use case I can think of :).

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

Oh I forgot about the issue of all those people with existing tables --
with your model we would have to force them to alter all their existing
tables to typmod explicit types if they wanted to still use
geometry_columns. I suspect that would take a long time with large tables.
Not to mention we would probably have to create a script to do that to
make it less painful.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

Do we want a painful migration or to be stuck with an ugly hack forever?

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

ugly hack. ugly hack. ugly hack. Ugly is in the eye of the beholder, but
pain is felt by everyone :)
Besides that's why I'm going for an ST_geometry_columns. That is what
SQL/MM says it should be called. So let's call the pure solution that and
then perhaps one day we can deprecate geometry_columns and then remove it.

I also don't want an old thing AddGeometryColumns camoflaging a new way.
If we are going to push people to do it the easy way CREATE TABLE ...
geometry(POINT,..);

Why confuse them with having the old do the new. At some point we might
want to deprecate AddgeometryColumns so its best people not rely on it to
do a new thing.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

How about we change geometry_columns to old_geometry_columns.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

You mean all the addgeometry stuff works against old_geometry_columns
(instead of geometry_columns_legacy). I'm indifferent about the name.

Just that geometry_columns be a view and should be a fuse of old and new.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

How do you think the view can fuse the old and new? It'll necessarily find
all the non-typmod'ed columns in the system tables along with the
typmodded ones...

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

SELECT all geometry columns with a geometry type (not like geometry)
UNION ALL
geometry_columns_old

How about this Paul, you go do your typmod thing since that's a known we
want and we have no differences in opinion how that should be done.

I'll do the view, the revision of all the management functions. I'll even
write the pre install script that renames peoples existing
geometry_columns should they have one and I'll submit this as a patch for
you to tear apart and do what you will with. Deal?

BTW: we also need to change the loader. I think as a clean beginning it
should check versions of PostGIS and for version of PostGIS 2.0+ it should
use the standard CREATE TABLE ...geometry(..) instead of the management
functions. Would be nice if we had a switch option to allow people to
choose the old addgeometrycolumns or new typmod behavior and default to
new behavior, but that should go in as a separate ticket I think.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by mcayland):

Gosh - this all sounds really really horrible and likely to come back and
bite us later. Hard.

It sounds as if we just need a generic "GEOMETRY" type we can put in the
typmod that will allow any type of geometry within the column. If you're
really foolish enough to be mixing geometry types in a single column then
you're definitely not adhering to the OGC standard, so I don't see lack of
adherence to the OGC specification being an issue here.

Oh and talking about OGC spec compliance - even if we do get rid of the
geometry_columns table, we still need to keep the AddGeometryColumn() and
DropGeometryColumn() functions, even if they don't actually end up doing
anything.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

Mark,

I think you missed my two main points
1) If we expect people tomove to PostGIS 2.0, there current tables built
with AddGeometryColumn should work as they did before. It would be
painful to have them alter their geometry columns to typmod. With that
said -- the postgresql catalog will be wrong for these geometries.

2) For inheritance tables -- it is not unusual and I don't think bad
practice to have each child have a separate geometry type (though it
should have the same srid and dimension). typmod simply doesn't work for
this model.

3) There are varying degrees -- e.g. I think for example Oracle doesn't
mind POLYGON/MULTIPOLYGON coexisting. Neither do ESRI Shapefiles. When
you have a polygon in must cases it is more efficient to keep it that way
than wrapping it in a multi wrapper. typmod doesn't work for this either.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by mcayland):

In these cases, my responses would be:

1) If we expect people tomove to PostGIS 2.0, there current tables built
with AddGeometryColumn? should work as they did before. It would be
painful to have them alter their geometry columns to typmod. With that
said -- the postgresql catalog will be wrong for these geometries.

This is something that could be automated as part of an upgrade. A script
can be run to check the uniqueness of the geometry types within a table -
if they are unique then we can update the catalog to represent the correct
value, otherwise we set the typmod to be a generic GEOMETRY instead.

And also - if we're going to make people do things like a dump/reload
(which they will need with the new geometry format in 2.0) we might as
well do other horrible things as part of the upgrade.

2) For inheritance tables -- it is not unusual and I don't think bad
practice to have each child have a separate geometry type (though it
should have the same srid and dimension). typmod simply doesn't work for
this model.

Again, set the typmod to a generic GEOMETRY type but then add your own
constraints on your child tables. I would say that mixing things in this
way is an advanced level feature.

3) There are varying degrees -- e.g. I think for example Oracle doesn't
mind POLYGON/MULTIPOLYGON coexisting. Neither do ESRI Shapefiles. When you
have a polygon in must cases it is more efficient to keep it that way than
wrapping it in a multi wrapper. typmod doesn't work for this either.

This one is more tricky - if it were me, I would just use MULTIPOLYGONS
with one polygon for single shapes. When you say more efficient, what
exactly do you mean here?

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

1) Automation is not what I was worrying about. I was more worried about
speed.
For example converting a varchar(50) to say a varchar(1000) takes a
painful amount of time for a large table. OF course I may be over
estimating this. I think if Paul goes ahead with the typmod, I can test
with a 10 million record table converting to typmod to see just how
painful it is.

I really think we should avoid updating the catalogs directly. too much
has changed betweenn 8.4-9.1 that I wouldn't want to risk screwing it up.
Besides the PostgreSQL devs really frown on those changes.

2) Okay I can concede to that. It's a bit inconvenient than using
addgeometrycolumn but I agree it's a more advanced use case and rare at
that.

3) I think a lot of the speed issues we have addressed for this. In the
past it was significantly faster doing checks with polygons than
multipolygons even when a multipolygon had only one polygon. This is
probalby more an issue with third party tools than PostGIS.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

Mark,

AddGeometryColumn is an OGC standard but seems to not be mentioned at all
in the SQL/MM specs and in the OGC it does call it a table that needs
registration. Same for DropGeometryColumn.

The SQL/MM spec (seciton ISO/IEC CD 13249-3:200x() I am looking at
doesn't even have geometry_columns but talks about
ST_GEOMETRY_COLUMNS (which is a view (living in ST_Information_Schema)
"which lists the columns whose declared type is ST_Geometry
or one of its subtypes;" ). Thus my suggestion that our pure solution
that only looks at the system catalogs be called ST_Geometry_Columns and
that geometry_columns be a hybrid.

One additional note. Given the amount of back and forth we have had on
this topic, I think this one calls for an RFC of how exactly we propose to
change this. I think typmod is great and we should go ahead with that so
its really the question of how to manage the metadata. To me this is a
fundamental change in the way people operate and the way we will be
recommending people to operate so it needs more consideration and
documentation.

I also think we should bring this up to discussion in regular postgis
users group
to get a better population metric of its impact and people's thoughts on
the matter (particularly people managing viewers and other tools that use
postgis). I'm only guessing based on my personal use cases, but I'm sure
there are a lot more we haven't thought about.

strk also mentioned that INSPIRE would like to keep track of additional
information beyond what is allowed in geometry_columns and making this a
system catalog only query view will make that worse. True its a side
issue, but thought I would bring it up as a topic for discussion.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)

#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

My gut feeling says we should keep AddGeometryColumn, populate etc. more
or less as is so they still do the add constraint thing and register into
geometry_columns or a new table called

geometry_columns_legacy;

So here is my thought for merging the old with the new world.

st_geometry_columns -- a view parallel in concept to geography_columns
that just inspects the catalogs -- perhaps just leaves out geometry
columns with no typmod info (or includes them I guess marking them as just
geometry). this is a true SQL/MM implementation.

geometry_columns -- a view that unions st_geometry_columns (except for
those just marked as geometry) with geometry_columns_legacy. So old
applications can continue to work as they did before.

The populate, addgeometrycolumns etc. will just populate
geometry_columns_legacy. We will expect all people expecting the new
behavior to use the typmod behavior for creating geometries. It would
also only add constraints to columns that don't use typmod construction.

Any thoughts / issues people see?

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

I was hoping to just do it the same way geography does. A simple
geometry_columns view on the system tables. For backwards compatibility,
the Add/Remove utility functions can be simplified down to wrappers on
ALTER TABLE ADD COLUMN, etc.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

Normally I'd be the first to say down with the past except in this case
I'm not convinced the new way is always superior to the past. Then again I
think about my frustrating arguments with Josh Berkus how he thinks people
should just use text and put size checks on their fields. Feels funny
being on the other side of the argument.

If we are going to make the old functions wrappers around ALTER TABLE,
what am I going to do about my case when I want POLYGONS/MULTIPOLYGONS in
the same table because in many cases, there isn't any reason to treat them
separately. Also the case of inheritance. Now my work flow is so much
more complicated. Before I would just add it as a MULTIPOLYGON and
manually relax the type constraint to allow POLYGONS. Also the case with
the inheritance thing I talked about.

I know Paul is thinking "Why is it always about you, Regina?". Cause I'm
the first use case I can think of :).

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

Oh I forgot about the issue of all those people with existing tables --
with your model we would have to force them to alter all their existing
tables to typmod explicit types if they wanted to still use
geometry_columns. I suspect that would take a long time with large tables.
Not to mention we would probably have to create a script to do that to
make it less painful.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

Do we want a painful migration or to be stuck with an ugly hack forever?

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

ugly hack. ugly hack. ugly hack. Ugly is in the eye of the beholder, but
pain is felt by everyone :)
Besides that's why I'm going for an ST_geometry_columns. That is what
SQL/MM says it should be called. So let's call the pure solution that and
then perhaps one day we can deprecate geometry_columns and then remove it.

I also don't want an old thing AddGeometryColumns camoflaging a new way.
If we are going to push people to do it the easy way CREATE TABLE ...
geometry(POINT,..);

Why confuse them with having the old do the new. At some point we might
want to deprecate AddgeometryColumns so its best people not rely on it to
do a new thing.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

How about we change geometry_columns to old_geometry_columns.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

You mean all the addgeometry stuff works against old_geometry_columns
(instead of geometry_columns_legacy). I'm indifferent about the name.

Just that geometry_columns be a view and should be a fuse of old and new.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

How do you think the view can fuse the old and new? It'll necessarily find
all the non-typmod'ed columns in the system tables along with the
typmodded ones...

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

SELECT all geometry columns with a geometry type (not like geometry)
UNION ALL
geometry_columns_old

How about this Paul, you go do your typmod thing since that's a known we
want and we have no differences in opinion how that should be done.

I'll do the view, the revision of all the management functions. I'll even
write the pre install script that renames peoples existing
geometry_columns should they have one and I'll submit this as a patch for
you to tear apart and do what you will with. Deal?

BTW: we also need to change the loader. I think as a clean beginning it
should check versions of PostGIS and for version of PostGIS 2.0+ it should
use the standard CREATE TABLE ...geometry(..) instead of the management
functions. Would be nice if we had a switch option to allow people to
choose the old addgeometrycolumns or new typmod behavior and default to
new behavior, but that should go in as a separate ticket I think.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by mcayland):

Gosh - this all sounds really really horrible and likely to come back and
bite us later. Hard.

It sounds as if we just need a generic "GEOMETRY" type we can put in the
typmod that will allow any type of geometry within the column. If you're
really foolish enough to be mixing geometry types in a single column then
you're definitely not adhering to the OGC standard, so I don't see lack of
adherence to the OGC specification being an issue here.

Oh and talking about OGC spec compliance - even if we do get rid of the
geometry_columns table, we still need to keep the AddGeometryColumn() and
DropGeometryColumn() functions, even if they don't actually end up doing
anything.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

Mark,

I think you missed my two main points
1) If we expect people tomove to PostGIS 2.0, there current tables built
with AddGeometryColumn should work as they did before. It would be
painful to have them alter their geometry columns to typmod. With that
said -- the postgresql catalog will be wrong for these geometries.

2) For inheritance tables -- it is not unusual and I don't think bad
practice to have each child have a separate geometry type (though it
should have the same srid and dimension). typmod simply doesn't work for
this model.

3) There are varying degrees -- e.g. I think for example Oracle doesn't
mind POLYGON/MULTIPOLYGON coexisting. Neither do ESRI Shapefiles. When
you have a polygon in must cases it is more efficient to keep it that way
than wrapping it in a multi wrapper. typmod doesn't work for this either.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by mcayland):

In these cases, my responses would be:

1) If we expect people tomove to PostGIS 2.0, there current tables built
with AddGeometryColumn? should work as they did before. It would be
painful to have them alter their geometry columns to typmod. With that
said -- the postgresql catalog will be wrong for these geometries.

This is something that could be automated as part of an upgrade. A script
can be run to check the uniqueness of the geometry types within a table -
if they are unique then we can update the catalog to represent the correct
value, otherwise we set the typmod to be a generic GEOMETRY instead.

And also - if we're going to make people do things like a dump/reload
(which they will need with the new geometry format in 2.0) we might as
well do other horrible things as part of the upgrade.

2) For inheritance tables -- it is not unusual and I don't think bad
practice to have each child have a separate geometry type (though it
should have the same srid and dimension). typmod simply doesn't work for
this model.

Again, set the typmod to a generic GEOMETRY type but then add your own
constraints on your child tables. I would say that mixing things in this
way is an advanced level feature.

3) There are varying degrees -- e.g. I think for example Oracle doesn't
mind POLYGON/MULTIPOLYGON coexisting. Neither do ESRI Shapefiles. When you
have a polygon in must cases it is more efficient to keep it that way than
wrapping it in a multi wrapper. typmod doesn't work for this either.

This one is more tricky - if it were me, I would just use MULTIPOLYGONS
with one polygon for single shapes. When you say more efficient, what
exactly do you mean here?

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

1) Automation is not what I was worrying about. I was more worried about
speed.
For example converting a varchar(50) to say a varchar(1000) takes a
painful amount of time for a large table. OF course I may be over
estimating this. I think if Paul goes ahead with the typmod, I can test
with a 10 million record table converting to typmod to see just how
painful it is.

I really think we should avoid updating the catalogs directly. too much
has changed betweenn 8.4-9.1 that I wouldn't want to risk screwing it up.
Besides the PostgreSQL devs really frown on those changes.

2) Okay I can concede to that. It's a bit inconvenient than using
addgeometrycolumn but I agree it's a more advanced use case and rare at
that.

3) I think a lot of the speed issues we have addressed for this. In the
past it was significantly faster doing checks with polygons than
multipolygons even when a multipolygon had only one polygon. This is
probalby more an issue with third party tools than PostGIS.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

Mark,

AddGeometryColumn is an OGC standard but seems to not be mentioned at all
in the SQL/MM specs and in the OGC it does call it a table that needs
registration. Same for DropGeometryColumn.

The SQL/MM spec (seciton ISO/IEC CD 13249-3:200x() I am looking at
doesn't even have geometry_columns but talks about
ST_GEOMETRY_COLUMNS (which is a view (living in ST_Information_Schema)
"which lists the columns whose declared type is ST_Geometry
or one of its subtypes;" ). Thus my suggestion that our pure solution
that only looks at the system catalogs be called ST_Geometry_Columns and
that geometry_columns be a hybrid.

One additional note. Given the amount of back and forth we have had on
this topic, I think this one calls for an RFC of how exactly we propose to
change this. I think typmod is great and we should go ahead with that so
its really the question of how to manage the metadata. To me this is a
fundamental change in the way people operate and the way we will be
recommending people to operate so it needs more consideration and
documentation.

I also think we should bring this up to discussion in regular postgis
users group
to get a better population metric of its impact and people's thoughts on
the matter (particularly people managing viewers and other tools that use
postgis). I'm only guessing based on my personal use cases, but I'm sure
there are a lot more we haven't thought about.

strk also mentioned that INSPIRE would like to keep track of additional
information beyond what is allowed in geometry_columns and making this a
system catalog only query view will make that worse. True its a side
issue, but thought I would bring it up as a topic for discussion.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

Now i remember the use case why I have multipolygon/polygon. For one
project I am working on where we have our own flex renderer, its a pain to
output multipolygons especially since most of the records in the table are
singular polygons. I have 9,000,000 records of polygons/multipolygon for
example of which only 1000 are true multipolygons. Admittedly since we are
writing our own renderer, the registration issue in geometry_columns isn't
terribly important except when my client has to view these things like
Safe FME - as I recall he couldn't see the tables in his FME workbench
unless they were registered.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)

#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

My gut feeling says we should keep AddGeometryColumn, populate etc. more
or less as is so they still do the add constraint thing and register into
geometry_columns or a new table called

geometry_columns_legacy;

So here is my thought for merging the old with the new world.

st_geometry_columns -- a view parallel in concept to geography_columns
that just inspects the catalogs -- perhaps just leaves out geometry
columns with no typmod info (or includes them I guess marking them as just
geometry). this is a true SQL/MM implementation.

geometry_columns -- a view that unions st_geometry_columns (except for
those just marked as geometry) with geometry_columns_legacy. So old
applications can continue to work as they did before.

The populate, addgeometrycolumns etc. will just populate
geometry_columns_legacy. We will expect all people expecting the new
behavior to use the typmod behavior for creating geometries. It would
also only add constraints to columns that don't use typmod construction.

Any thoughts / issues people see?

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

I was hoping to just do it the same way geography does. A simple
geometry_columns view on the system tables. For backwards compatibility,
the Add/Remove utility functions can be simplified down to wrappers on
ALTER TABLE ADD COLUMN, etc.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

Normally I'd be the first to say down with the past except in this case
I'm not convinced the new way is always superior to the past. Then again I
think about my frustrating arguments with Josh Berkus how he thinks people
should just use text and put size checks on their fields. Feels funny
being on the other side of the argument.

If we are going to make the old functions wrappers around ALTER TABLE,
what am I going to do about my case when I want POLYGONS/MULTIPOLYGONS in
the same table because in many cases, there isn't any reason to treat them
separately. Also the case of inheritance. Now my work flow is so much
more complicated. Before I would just add it as a MULTIPOLYGON and
manually relax the type constraint to allow POLYGONS. Also the case with
the inheritance thing I talked about.

I know Paul is thinking "Why is it always about you, Regina?". Cause I'm
the first use case I can think of :).

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

Oh I forgot about the issue of all those people with existing tables --
with your model we would have to force them to alter all their existing
tables to typmod explicit types if they wanted to still use
geometry_columns. I suspect that would take a long time with large tables.
Not to mention we would probably have to create a script to do that to
make it less painful.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

Do we want a painful migration or to be stuck with an ugly hack forever?

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

ugly hack. ugly hack. ugly hack. Ugly is in the eye of the beholder, but
pain is felt by everyone :)
Besides that's why I'm going for an ST_geometry_columns. That is what
SQL/MM says it should be called. So let's call the pure solution that and
then perhaps one day we can deprecate geometry_columns and then remove it.

I also don't want an old thing AddGeometryColumns camoflaging a new way.
If we are going to push people to do it the easy way CREATE TABLE ...
geometry(POINT,..);

Why confuse them with having the old do the new. At some point we might
want to deprecate AddgeometryColumns so its best people not rely on it to
do a new thing.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

How about we change geometry_columns to old_geometry_columns.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

You mean all the addgeometry stuff works against old_geometry_columns
(instead of geometry_columns_legacy). I'm indifferent about the name.

Just that geometry_columns be a view and should be a fuse of old and new.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

How do you think the view can fuse the old and new? It'll necessarily find
all the non-typmod'ed columns in the system tables along with the
typmodded ones...

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

SELECT all geometry columns with a geometry type (not like geometry)
UNION ALL
geometry_columns_old

How about this Paul, you go do your typmod thing since that's a known we
want and we have no differences in opinion how that should be done.

I'll do the view, the revision of all the management functions. I'll even
write the pre install script that renames peoples existing
geometry_columns should they have one and I'll submit this as a patch for
you to tear apart and do what you will with. Deal?

BTW: we also need to change the loader. I think as a clean beginning it
should check versions of PostGIS and for version of PostGIS 2.0+ it should
use the standard CREATE TABLE ...geometry(..) instead of the management
functions. Would be nice if we had a switch option to allow people to
choose the old addgeometrycolumns or new typmod behavior and default to
new behavior, but that should go in as a separate ticket I think.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by mcayland):

Gosh - this all sounds really really horrible and likely to come back and
bite us later. Hard.

It sounds as if we just need a generic "GEOMETRY" type we can put in the
typmod that will allow any type of geometry within the column. If you're
really foolish enough to be mixing geometry types in a single column then
you're definitely not adhering to the OGC standard, so I don't see lack of
adherence to the OGC specification being an issue here.

Oh and talking about OGC spec compliance - even if we do get rid of the
geometry_columns table, we still need to keep the AddGeometryColumn() and
DropGeometryColumn() functions, even if they don't actually end up doing
anything.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

Mark,

I think you missed my two main points
1) If we expect people tomove to PostGIS 2.0, there current tables built
with AddGeometryColumn should work as they did before. It would be
painful to have them alter their geometry columns to typmod. With that
said -- the postgresql catalog will be wrong for these geometries.

2) For inheritance tables -- it is not unusual and I don't think bad
practice to have each child have a separate geometry type (though it
should have the same srid and dimension). typmod simply doesn't work for
this model.

3) There are varying degrees -- e.g. I think for example Oracle doesn't
mind POLYGON/MULTIPOLYGON coexisting. Neither do ESRI Shapefiles. When
you have a polygon in must cases it is more efficient to keep it that way
than wrapping it in a multi wrapper. typmod doesn't work for this either.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by mcayland):

In these cases, my responses would be:

1) If we expect people tomove to PostGIS 2.0, there current tables built
with AddGeometryColumn? should work as they did before. It would be
painful to have them alter their geometry columns to typmod. With that
said -- the postgresql catalog will be wrong for these geometries.

This is something that could be automated as part of an upgrade. A script
can be run to check the uniqueness of the geometry types within a table -
if they are unique then we can update the catalog to represent the correct
value, otherwise we set the typmod to be a generic GEOMETRY instead.

And also - if we're going to make people do things like a dump/reload
(which they will need with the new geometry format in 2.0) we might as
well do other horrible things as part of the upgrade.

2) For inheritance tables -- it is not unusual and I don't think bad
practice to have each child have a separate geometry type (though it
should have the same srid and dimension). typmod simply doesn't work for
this model.

Again, set the typmod to a generic GEOMETRY type but then add your own
constraints on your child tables. I would say that mixing things in this
way is an advanced level feature.

3) There are varying degrees -- e.g. I think for example Oracle doesn't
mind POLYGON/MULTIPOLYGON coexisting. Neither do ESRI Shapefiles. When you
have a polygon in must cases it is more efficient to keep it that way than
wrapping it in a multi wrapper. typmod doesn't work for this either.

This one is more tricky - if it were me, I would just use MULTIPOLYGONS
with one polygon for single shapes. When you say more efficient, what
exactly do you mean here?

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

1) Automation is not what I was worrying about. I was more worried about
speed.
For example converting a varchar(50) to say a varchar(1000) takes a
painful amount of time for a large table. OF course I may be over
estimating this. I think if Paul goes ahead with the typmod, I can test
with a 10 million record table converting to typmod to see just how
painful it is.

I really think we should avoid updating the catalogs directly. too much
has changed betweenn 8.4-9.1 that I wouldn't want to risk screwing it up.
Besides the PostgreSQL devs really frown on those changes.

2) Okay I can concede to that. It's a bit inconvenient than using
addgeometrycolumn but I agree it's a more advanced use case and rare at
that.

3) I think a lot of the speed issues we have addressed for this. In the
past it was significantly faster doing checks with polygons than
multipolygons even when a multipolygon had only one polygon. This is
probalby more an issue with third party tools than PostGIS.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

Mark,

AddGeometryColumn is an OGC standard but seems to not be mentioned at all
in the SQL/MM specs and in the OGC it does call it a table that needs
registration. Same for DropGeometryColumn.

The SQL/MM spec (seciton ISO/IEC CD 13249-3:200x() I am looking at
doesn't even have geometry_columns but talks about
ST_GEOMETRY_COLUMNS (which is a view (living in ST_Information_Schema)
"which lists the columns whose declared type is ST_Geometry
or one of its subtypes;" ). Thus my suggestion that our pure solution
that only looks at the system catalogs be called ST_Geometry_Columns and
that geometry_columns be a hybrid.

One additional note. Given the amount of back and forth we have had on
this topic, I think this one calls for an RFC of how exactly we propose to
change this. I think typmod is great and we should go ahead with that so
its really the question of how to manage the metadata. To me this is a
fundamental change in the way people operate and the way we will be
recommending people to operate so it needs more consideration and
documentation.

I also think we should bring this up to discussion in regular postgis
users group
to get a better population metric of its impact and people's thoughts on
the matter (particularly people managing viewers and other tools that use
postgis). I'm only guessing based on my personal use cases, but I'm sure
there are a lot more we haven't thought about.

strk also mentioned that INSPIRE would like to keep track of additional
information beyond what is allowed in geometry_columns and making this a
system catalog only query view will make that worse. True its a side
issue, but thought I would bring it up as a topic for discussion.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

Now i remember the use case why I have multipolygon/polygon. For one
project I am working on where we have our own flex renderer, its a pain to
output multipolygons especially since most of the records in the table are
singular polygons. I have 9,000,000 records of polygons/multipolygon for
example of which only 1000 are true multipolygons. Admittedly since we are
writing our own renderer, the registration issue in geometry_columns isn't
terribly important except when my client has to view these things like
Safe FME - as I recall he couldn't see the tables in his FME workbench
unless they were registered.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by mcayland):

I think that if we went as far as having a hybrid solution, it would just
cause even more chaos in the long run. As Paul mentions up-thread, do we
want to be stuck with an ugly hack forever?

For point 1, converting a varchar(50) to a varchar(1000) can be done
easily with a single catalog query because the internal representation
doesn't change. In the same way that setting a typmod for a mixed column
can be done in the same way because by changing from a sub-class to a
super-class, we can guarantee that all of the criteria can be met and so
we don't need to check every single row. We would have to visit every row
if going the other way, but I don't think that's the common use case.

For point 3, I think we would need to see which tools have these issues in
order to get a feel for whether or not this would be a real problem.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)

#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

My gut feeling says we should keep AddGeometryColumn, populate etc. more
or less as is so they still do the add constraint thing and register into
geometry_columns or a new table called

geometry_columns_legacy;

So here is my thought for merging the old with the new world.

st_geometry_columns -- a view parallel in concept to geography_columns
that just inspects the catalogs -- perhaps just leaves out geometry
columns with no typmod info (or includes them I guess marking them as just
geometry). this is a true SQL/MM implementation.

geometry_columns -- a view that unions st_geometry_columns (except for
those just marked as geometry) with geometry_columns_legacy. So old
applications can continue to work as they did before.

The populate, addgeometrycolumns etc. will just populate
geometry_columns_legacy. We will expect all people expecting the new
behavior to use the typmod behavior for creating geometries. It would
also only add constraints to columns that don't use typmod construction.

Any thoughts / issues people see?

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

I was hoping to just do it the same way geography does. A simple
geometry_columns view on the system tables. For backwards compatibility,
the Add/Remove utility functions can be simplified down to wrappers on
ALTER TABLE ADD COLUMN, etc.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

Normally I'd be the first to say down with the past except in this case
I'm not convinced the new way is always superior to the past. Then again I
think about my frustrating arguments with Josh Berkus how he thinks people
should just use text and put size checks on their fields. Feels funny
being on the other side of the argument.

If we are going to make the old functions wrappers around ALTER TABLE,
what am I going to do about my case when I want POLYGONS/MULTIPOLYGONS in
the same table because in many cases, there isn't any reason to treat them
separately. Also the case of inheritance. Now my work flow is so much
more complicated. Before I would just add it as a MULTIPOLYGON and
manually relax the type constraint to allow POLYGONS. Also the case with
the inheritance thing I talked about.

I know Paul is thinking "Why is it always about you, Regina?". Cause I'm
the first use case I can think of :).

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

Oh I forgot about the issue of all those people with existing tables --
with your model we would have to force them to alter all their existing
tables to typmod explicit types if they wanted to still use
geometry_columns. I suspect that would take a long time with large tables.
Not to mention we would probably have to create a script to do that to
make it less painful.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

Do we want a painful migration or to be stuck with an ugly hack forever?

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

ugly hack. ugly hack. ugly hack. Ugly is in the eye of the beholder, but
pain is felt by everyone :)
Besides that's why I'm going for an ST_geometry_columns. That is what
SQL/MM says it should be called. So let's call the pure solution that and
then perhaps one day we can deprecate geometry_columns and then remove it.

I also don't want an old thing AddGeometryColumns camoflaging a new way.
If we are going to push people to do it the easy way CREATE TABLE ...
geometry(POINT,..);

Why confuse them with having the old do the new. At some point we might
want to deprecate AddgeometryColumns so its best people not rely on it to
do a new thing.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

How about we change geometry_columns to old_geometry_columns.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

You mean all the addgeometry stuff works against old_geometry_columns
(instead of geometry_columns_legacy). I'm indifferent about the name.

Just that geometry_columns be a view and should be a fuse of old and new.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

How do you think the view can fuse the old and new? It'll necessarily find
all the non-typmod'ed columns in the system tables along with the
typmodded ones...

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

SELECT all geometry columns with a geometry type (not like geometry)
UNION ALL
geometry_columns_old

How about this Paul, you go do your typmod thing since that's a known we
want and we have no differences in opinion how that should be done.

I'll do the view, the revision of all the management functions. I'll even
write the pre install script that renames peoples existing
geometry_columns should they have one and I'll submit this as a patch for
you to tear apart and do what you will with. Deal?

BTW: we also need to change the loader. I think as a clean beginning it
should check versions of PostGIS and for version of PostGIS 2.0+ it should
use the standard CREATE TABLE ...geometry(..) instead of the management
functions. Would be nice if we had a switch option to allow people to
choose the old addgeometrycolumns or new typmod behavior and default to
new behavior, but that should go in as a separate ticket I think.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by mcayland):

Gosh - this all sounds really really horrible and likely to come back and
bite us later. Hard.

It sounds as if we just need a generic "GEOMETRY" type we can put in the
typmod that will allow any type of geometry within the column. If you're
really foolish enough to be mixing geometry types in a single column then
you're definitely not adhering to the OGC standard, so I don't see lack of
adherence to the OGC specification being an issue here.

Oh and talking about OGC spec compliance - even if we do get rid of the
geometry_columns table, we still need to keep the AddGeometryColumn() and
DropGeometryColumn() functions, even if they don't actually end up doing
anything.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

Mark,

I think you missed my two main points
1) If we expect people tomove to PostGIS 2.0, there current tables built
with AddGeometryColumn should work as they did before. It would be
painful to have them alter their geometry columns to typmod. With that
said -- the postgresql catalog will be wrong for these geometries.

2) For inheritance tables -- it is not unusual and I don't think bad
practice to have each child have a separate geometry type (though it
should have the same srid and dimension). typmod simply doesn't work for
this model.

3) There are varying degrees -- e.g. I think for example Oracle doesn't
mind POLYGON/MULTIPOLYGON coexisting. Neither do ESRI Shapefiles. When
you have a polygon in must cases it is more efficient to keep it that way
than wrapping it in a multi wrapper. typmod doesn't work for this either.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by mcayland):

In these cases, my responses would be:

1) If we expect people tomove to PostGIS 2.0, there current tables built
with AddGeometryColumn? should work as they did before. It would be
painful to have them alter their geometry columns to typmod. With that
said -- the postgresql catalog will be wrong for these geometries.

This is something that could be automated as part of an upgrade. A script
can be run to check the uniqueness of the geometry types within a table -
if they are unique then we can update the catalog to represent the correct
value, otherwise we set the typmod to be a generic GEOMETRY instead.

And also - if we're going to make people do things like a dump/reload
(which they will need with the new geometry format in 2.0) we might as
well do other horrible things as part of the upgrade.

2) For inheritance tables -- it is not unusual and I don't think bad
practice to have each child have a separate geometry type (though it
should have the same srid and dimension). typmod simply doesn't work for
this model.

Again, set the typmod to a generic GEOMETRY type but then add your own
constraints on your child tables. I would say that mixing things in this
way is an advanced level feature.

3) There are varying degrees -- e.g. I think for example Oracle doesn't
mind POLYGON/MULTIPOLYGON coexisting. Neither do ESRI Shapefiles. When you
have a polygon in must cases it is more efficient to keep it that way than
wrapping it in a multi wrapper. typmod doesn't work for this either.

This one is more tricky - if it were me, I would just use MULTIPOLYGONS
with one polygon for single shapes. When you say more efficient, what
exactly do you mean here?

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

1) Automation is not what I was worrying about. I was more worried about
speed.
For example converting a varchar(50) to say a varchar(1000) takes a
painful amount of time for a large table. OF course I may be over
estimating this. I think if Paul goes ahead with the typmod, I can test
with a 10 million record table converting to typmod to see just how
painful it is.

I really think we should avoid updating the catalogs directly. too much
has changed betweenn 8.4-9.1 that I wouldn't want to risk screwing it up.
Besides the PostgreSQL devs really frown on those changes.

2) Okay I can concede to that. It's a bit inconvenient than using
addgeometrycolumn but I agree it's a more advanced use case and rare at
that.

3) I think a lot of the speed issues we have addressed for this. In the
past it was significantly faster doing checks with polygons than
multipolygons even when a multipolygon had only one polygon. This is
probalby more an issue with third party tools than PostGIS.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

Mark,

AddGeometryColumn is an OGC standard but seems to not be mentioned at all
in the SQL/MM specs and in the OGC it does call it a table that needs
registration. Same for DropGeometryColumn.

The SQL/MM spec (seciton ISO/IEC CD 13249-3:200x() I am looking at
doesn't even have geometry_columns but talks about
ST_GEOMETRY_COLUMNS (which is a view (living in ST_Information_Schema)
"which lists the columns whose declared type is ST_Geometry
or one of its subtypes;" ). Thus my suggestion that our pure solution
that only looks at the system catalogs be called ST_Geometry_Columns and
that geometry_columns be a hybrid.

One additional note. Given the amount of back and forth we have had on
this topic, I think this one calls for an RFC of how exactly we propose to
change this. I think typmod is great and we should go ahead with that so
its really the question of how to manage the metadata. To me this is a
fundamental change in the way people operate and the way we will be
recommending people to operate so it needs more consideration and
documentation.

I also think we should bring this up to discussion in regular postgis
users group
to get a better population metric of its impact and people's thoughts on
the matter (particularly people managing viewers and other tools that use
postgis). I'm only guessing based on my personal use cases, but I'm sure
there are a lot more we haven't thought about.

strk also mentioned that INSPIRE would like to keep track of additional
information beyond what is allowed in geometry_columns and making this a
system catalog only query view will make that worse. True its a side
issue, but thought I would bring it up as a topic for discussion.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

Now i remember the use case why I have multipolygon/polygon. For one
project I am working on where we have our own flex renderer, its a pain to
output multipolygons especially since most of the records in the table are
singular polygons. I have 9,000,000 records of polygons/multipolygon for
example of which only 1000 are true multipolygons. Admittedly since we are
writing our own renderer, the registration issue in geometry_columns isn't
terribly important except when my client has to view these things like
Safe FME - as I recall he couldn't see the tables in his FME workbench
unless they were registered.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by mcayland):

I think that if we went as far as having a hybrid solution, it would just
cause even more chaos in the long run. As Paul mentions up-thread, do we
want to be stuck with an ugly hack forever?

For point 1, converting a varchar(50) to a varchar(1000) can be done
easily with a single catalog query because the internal representation
doesn't change. In the same way that setting a typmod for a mixed column
can be done in the same way because by changing from a sub-class to a
super-class, we can guarantee that all of the criteria can be met and so
we don't need to check every single row. We would have to visit every row
if going the other way, but I don't think that's the common use case.

For point 3, I think we would need to see which tools have these issues in
order to get a feel for whether or not this would be a real problem.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

I think both you are Paul overestimate the length of forever. To me
forever (in software terms) is at best 3 years. If you believe the
doomsday sayers, it will be like a week from now.

A view can be easily changed whenever we want really, heck that's the
point of having a view -- to hide the underlying complexity of your system
and change it when you don't like it anymore. What you are proposing
violates with fiddling with catalogs violates the PostgreSQL development
policy and is much harder to backout than what I am proposing.

Anyrate my point is we don't really need to make this decision quite just
yet. We want typmod, we are all in agreement with that, so we should go
ahead with that piece and test applications and various scenarios to know
which way to go with the second part.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)

#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

My gut feeling says we should keep AddGeometryColumn, populate etc. more
or less as is so they still do the add constraint thing and register into
geometry_columns or a new table called

geometry_columns_legacy;

So here is my thought for merging the old with the new world.

st_geometry_columns -- a view parallel in concept to geography_columns
that just inspects the catalogs -- perhaps just leaves out geometry
columns with no typmod info (or includes them I guess marking them as just
geometry). this is a true SQL/MM implementation.

geometry_columns -- a view that unions st_geometry_columns (except for
those just marked as geometry) with geometry_columns_legacy. So old
applications can continue to work as they did before.

The populate, addgeometrycolumns etc. will just populate
geometry_columns_legacy. We will expect all people expecting the new
behavior to use the typmod behavior for creating geometries. It would
also only add constraints to columns that don't use typmod construction.

Any thoughts / issues people see?

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

I was hoping to just do it the same way geography does. A simple
geometry_columns view on the system tables. For backwards compatibility,
the Add/Remove utility functions can be simplified down to wrappers on
ALTER TABLE ADD COLUMN, etc.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

Normally I'd be the first to say down with the past except in this case
I'm not convinced the new way is always superior to the past. Then again I
think about my frustrating arguments with Josh Berkus how he thinks people
should just use text and put size checks on their fields. Feels funny
being on the other side of the argument.

If we are going to make the old functions wrappers around ALTER TABLE,
what am I going to do about my case when I want POLYGONS/MULTIPOLYGONS in
the same table because in many cases, there isn't any reason to treat them
separately. Also the case of inheritance. Now my work flow is so much
more complicated. Before I would just add it as a MULTIPOLYGON and
manually relax the type constraint to allow POLYGONS. Also the case with
the inheritance thing I talked about.

I know Paul is thinking "Why is it always about you, Regina?". Cause I'm
the first use case I can think of :).

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

Oh I forgot about the issue of all those people with existing tables --
with your model we would have to force them to alter all their existing
tables to typmod explicit types if they wanted to still use
geometry_columns. I suspect that would take a long time with large tables.
Not to mention we would probably have to create a script to do that to
make it less painful.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

Do we want a painful migration or to be stuck with an ugly hack forever?

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

ugly hack. ugly hack. ugly hack. Ugly is in the eye of the beholder, but
pain is felt by everyone :)
Besides that's why I'm going for an ST_geometry_columns. That is what
SQL/MM says it should be called. So let's call the pure solution that and
then perhaps one day we can deprecate geometry_columns and then remove it.

I also don't want an old thing AddGeometryColumns camoflaging a new way.
If we are going to push people to do it the easy way CREATE TABLE ...
geometry(POINT,..);

Why confuse them with having the old do the new. At some point we might
want to deprecate AddgeometryColumns so its best people not rely on it to
do a new thing.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

How about we change geometry_columns to old_geometry_columns.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

You mean all the addgeometry stuff works against old_geometry_columns
(instead of geometry_columns_legacy). I'm indifferent about the name.

Just that geometry_columns be a view and should be a fuse of old and new.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

How do you think the view can fuse the old and new? It'll necessarily find
all the non-typmod'ed columns in the system tables along with the
typmodded ones...

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

SELECT all geometry columns with a geometry type (not like geometry)
UNION ALL
geometry_columns_old

How about this Paul, you go do your typmod thing since that's a known we
want and we have no differences in opinion how that should be done.

I'll do the view, the revision of all the management functions. I'll even
write the pre install script that renames peoples existing
geometry_columns should they have one and I'll submit this as a patch for
you to tear apart and do what you will with. Deal?

BTW: we also need to change the loader. I think as a clean beginning it
should check versions of PostGIS and for version of PostGIS 2.0+ it should
use the standard CREATE TABLE ...geometry(..) instead of the management
functions. Would be nice if we had a switch option to allow people to
choose the old addgeometrycolumns or new typmod behavior and default to
new behavior, but that should go in as a separate ticket I think.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by mcayland):

Gosh - this all sounds really really horrible and likely to come back and
bite us later. Hard.

It sounds as if we just need a generic "GEOMETRY" type we can put in the
typmod that will allow any type of geometry within the column. If you're
really foolish enough to be mixing geometry types in a single column then
you're definitely not adhering to the OGC standard, so I don't see lack of
adherence to the OGC specification being an issue here.

Oh and talking about OGC spec compliance - even if we do get rid of the
geometry_columns table, we still need to keep the AddGeometryColumn() and
DropGeometryColumn() functions, even if they don't actually end up doing
anything.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

Mark,

I think you missed my two main points
1) If we expect people tomove to PostGIS 2.0, there current tables built
with AddGeometryColumn should work as they did before. It would be
painful to have them alter their geometry columns to typmod. With that
said -- the postgresql catalog will be wrong for these geometries.

2) For inheritance tables -- it is not unusual and I don't think bad
practice to have each child have a separate geometry type (though it
should have the same srid and dimension). typmod simply doesn't work for
this model.

3) There are varying degrees -- e.g. I think for example Oracle doesn't
mind POLYGON/MULTIPOLYGON coexisting. Neither do ESRI Shapefiles. When
you have a polygon in must cases it is more efficient to keep it that way
than wrapping it in a multi wrapper. typmod doesn't work for this either.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by mcayland):

In these cases, my responses would be:

1) If we expect people tomove to PostGIS 2.0, there current tables built
with AddGeometryColumn? should work as they did before. It would be
painful to have them alter their geometry columns to typmod. With that
said -- the postgresql catalog will be wrong for these geometries.

This is something that could be automated as part of an upgrade. A script
can be run to check the uniqueness of the geometry types within a table -
if they are unique then we can update the catalog to represent the correct
value, otherwise we set the typmod to be a generic GEOMETRY instead.

And also - if we're going to make people do things like a dump/reload
(which they will need with the new geometry format in 2.0) we might as
well do other horrible things as part of the upgrade.

2) For inheritance tables -- it is not unusual and I don't think bad
practice to have each child have a separate geometry type (though it
should have the same srid and dimension). typmod simply doesn't work for
this model.

Again, set the typmod to a generic GEOMETRY type but then add your own
constraints on your child tables. I would say that mixing things in this
way is an advanced level feature.

3) There are varying degrees -- e.g. I think for example Oracle doesn't
mind POLYGON/MULTIPOLYGON coexisting. Neither do ESRI Shapefiles. When you
have a polygon in must cases it is more efficient to keep it that way than
wrapping it in a multi wrapper. typmod doesn't work for this either.

This one is more tricky - if it were me, I would just use MULTIPOLYGONS
with one polygon for single shapes. When you say more efficient, what
exactly do you mean here?

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

1) Automation is not what I was worrying about. I was more worried about
speed.
For example converting a varchar(50) to say a varchar(1000) takes a
painful amount of time for a large table. OF course I may be over
estimating this. I think if Paul goes ahead with the typmod, I can test
with a 10 million record table converting to typmod to see just how
painful it is.

I really think we should avoid updating the catalogs directly. too much
has changed betweenn 8.4-9.1 that I wouldn't want to risk screwing it up.
Besides the PostgreSQL devs really frown on those changes.

2) Okay I can concede to that. It's a bit inconvenient than using
addgeometrycolumn but I agree it's a more advanced use case and rare at
that.

3) I think a lot of the speed issues we have addressed for this. In the
past it was significantly faster doing checks with polygons than
multipolygons even when a multipolygon had only one polygon. This is
probalby more an issue with third party tools than PostGIS.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

Mark,

AddGeometryColumn is an OGC standard but seems to not be mentioned at all
in the SQL/MM specs and in the OGC it does call it a table that needs
registration. Same for DropGeometryColumn.

The SQL/MM spec (seciton ISO/IEC CD 13249-3:200x() I am looking at
doesn't even have geometry_columns but talks about
ST_GEOMETRY_COLUMNS (which is a view (living in ST_Information_Schema)
"which lists the columns whose declared type is ST_Geometry
or one of its subtypes;" ). Thus my suggestion that our pure solution
that only looks at the system catalogs be called ST_Geometry_Columns and
that geometry_columns be a hybrid.

One additional note. Given the amount of back and forth we have had on
this topic, I think this one calls for an RFC of how exactly we propose to
change this. I think typmod is great and we should go ahead with that so
its really the question of how to manage the metadata. To me this is a
fundamental change in the way people operate and the way we will be
recommending people to operate so it needs more consideration and
documentation.

I also think we should bring this up to discussion in regular postgis
users group
to get a better population metric of its impact and people's thoughts on
the matter (particularly people managing viewers and other tools that use
postgis). I'm only guessing based on my personal use cases, but I'm sure
there are a lot more we haven't thought about.

strk also mentioned that INSPIRE would like to keep track of additional
information beyond what is allowed in geometry_columns and making this a
system catalog only query view will make that worse. True its a side
issue, but thought I would bring it up as a topic for discussion.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

Now i remember the use case why I have multipolygon/polygon. For one
project I am working on where we have our own flex renderer, its a pain to
output multipolygons especially since most of the records in the table are
singular polygons. I have 9,000,000 records of polygons/multipolygon for
example of which only 1000 are true multipolygons. Admittedly since we are
writing our own renderer, the registration issue in geometry_columns isn't
terribly important except when my client has to view these things like
Safe FME - as I recall he couldn't see the tables in his FME workbench
unless they were registered.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by mcayland):

I think that if we went as far as having a hybrid solution, it would just
cause even more chaos in the long run. As Paul mentions up-thread, do we
want to be stuck with an ugly hack forever?

For point 1, converting a varchar(50) to a varchar(1000) can be done
easily with a single catalog query because the internal representation
doesn't change. In the same way that setting a typmod for a mixed column
can be done in the same way because by changing from a sub-class to a
super-class, we can guarantee that all of the criteria can be met and so
we don't need to check every single row. We would have to visit every row
if going the other way, but I don't think that's the common use case.

For point 3, I think we would need to see which tools have these issues in
order to get a feel for whether or not this would be a real problem.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

I think both you are Paul overestimate the length of forever. To me
forever (in software terms) is at best 3 years. If you believe the
doomsday sayers, it will be like a week from now.

A view can be easily changed whenever we want really, heck that's the
point of having a view -- to hide the underlying complexity of your system
and change it when you don't like it anymore. What you are proposing
violates with fiddling with catalogs violates the PostgreSQL development
policy and is much harder to backout than what I am proposing.

Anyrate my point is we don't really need to make this decision quite just
yet. We want typmod, we are all in agreement with that, so we should go
ahead with that piece and test applications and various scenarios to know
which way to go with the second part.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by mcayland):

I don't think changing the catalogs is violating the PostgreSQL
development policy - for example, until reasonably recently the
operator/operator class definitions were all done by inserting/updating
the catalogs directly because the operator and operator class functions
did not contain sufficient functionality at the time.

Sure you can shoot yourself in the foot if you don't know what you're
doing with the catalogs, but I don't see much elevated risk performing an
upgrade that involves running a pre-packaged, test script.

I agree with you that we should probably spin this out into a separate
thread on postgis-users. If people are doing interesting things with their
geometry columns, then that's where we'll find out about it.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)

#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

My gut feeling says we should keep AddGeometryColumn, populate etc. more
or less as is so they still do the add constraint thing and register into
geometry_columns or a new table called

geometry_columns_legacy;

So here is my thought for merging the old with the new world.

st_geometry_columns -- a view parallel in concept to geography_columns
that just inspects the catalogs -- perhaps just leaves out geometry
columns with no typmod info (or includes them I guess marking them as just
geometry). this is a true SQL/MM implementation.

geometry_columns -- a view that unions st_geometry_columns (except for
those just marked as geometry) with geometry_columns_legacy. So old
applications can continue to work as they did before.

The populate, addgeometrycolumns etc. will just populate
geometry_columns_legacy. We will expect all people expecting the new
behavior to use the typmod behavior for creating geometries. It would
also only add constraints to columns that don't use typmod construction.

Any thoughts / issues people see?

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

I was hoping to just do it the same way geography does. A simple
geometry_columns view on the system tables. For backwards compatibility,
the Add/Remove utility functions can be simplified down to wrappers on
ALTER TABLE ADD COLUMN, etc.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

Normally I'd be the first to say down with the past except in this case
I'm not convinced the new way is always superior to the past. Then again I
think about my frustrating arguments with Josh Berkus how he thinks people
should just use text and put size checks on their fields. Feels funny
being on the other side of the argument.

If we are going to make the old functions wrappers around ALTER TABLE,
what am I going to do about my case when I want POLYGONS/MULTIPOLYGONS in
the same table because in many cases, there isn't any reason to treat them
separately. Also the case of inheritance. Now my work flow is so much
more complicated. Before I would just add it as a MULTIPOLYGON and
manually relax the type constraint to allow POLYGONS. Also the case with
the inheritance thing I talked about.

I know Paul is thinking "Why is it always about you, Regina?". Cause I'm
the first use case I can think of :).

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

Oh I forgot about the issue of all those people with existing tables --
with your model we would have to force them to alter all their existing
tables to typmod explicit types if they wanted to still use
geometry_columns. I suspect that would take a long time with large tables.
Not to mention we would probably have to create a script to do that to
make it less painful.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

Do we want a painful migration or to be stuck with an ugly hack forever?

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

ugly hack. ugly hack. ugly hack. Ugly is in the eye of the beholder, but
pain is felt by everyone :)
Besides that's why I'm going for an ST_geometry_columns. That is what
SQL/MM says it should be called. So let's call the pure solution that and
then perhaps one day we can deprecate geometry_columns and then remove it.

I also don't want an old thing AddGeometryColumns camoflaging a new way.
If we are going to push people to do it the easy way CREATE TABLE ...
geometry(POINT,..);

Why confuse them with having the old do the new. At some point we might
want to deprecate AddgeometryColumns so its best people not rely on it to
do a new thing.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

How about we change geometry_columns to old_geometry_columns.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

You mean all the addgeometry stuff works against old_geometry_columns
(instead of geometry_columns_legacy). I'm indifferent about the name.

Just that geometry_columns be a view and should be a fuse of old and new.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by pramsey):

How do you think the view can fuse the old and new? It'll necessarily find
all the non-typmod'ed columns in the system tables along with the
typmodded ones...

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

SELECT all geometry columns with a geometry type (not like geometry)
UNION ALL
geometry_columns_old

How about this Paul, you go do your typmod thing since that's a known we
want and we have no differences in opinion how that should be done.

I'll do the view, the revision of all the management functions. I'll even
write the pre install script that renames peoples existing
geometry_columns should they have one and I'll submit this as a patch for
you to tear apart and do what you will with. Deal?

BTW: we also need to change the loader. I think as a clean beginning it
should check versions of PostGIS and for version of PostGIS 2.0+ it should
use the standard CREATE TABLE ...geometry(..) instead of the management
functions. Would be nice if we had a switch option to allow people to
choose the old addgeometrycolumns or new typmod behavior and default to
new behavior, but that should go in as a separate ticket I think.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by mcayland):

Gosh - this all sounds really really horrible and likely to come back and
bite us later. Hard.

It sounds as if we just need a generic "GEOMETRY" type we can put in the
typmod that will allow any type of geometry within the column. If you're
really foolish enough to be mixing geometry types in a single column then
you're definitely not adhering to the OGC standard, so I don't see lack of
adherence to the OGC specification being an issue here.

Oh and talking about OGC spec compliance - even if we do get rid of the
geometry_columns table, we still need to keep the AddGeometryColumn() and
DropGeometryColumn() functions, even if they don't actually end up doing
anything.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

Mark,

I think you missed my two main points
1) If we expect people tomove to PostGIS 2.0, there current tables built
with AddGeometryColumn should work as they did before. It would be
painful to have them alter their geometry columns to typmod. With that
said -- the postgresql catalog will be wrong for these geometries.

2) For inheritance tables -- it is not unusual and I don't think bad
practice to have each child have a separate geometry type (though it
should have the same srid and dimension). typmod simply doesn't work for
this model.

3) There are varying degrees -- e.g. I think for example Oracle doesn't
mind POLYGON/MULTIPOLYGON coexisting. Neither do ESRI Shapefiles. When
you have a polygon in must cases it is more efficient to keep it that way
than wrapping it in a multi wrapper. typmod doesn't work for this either.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by mcayland):

In these cases, my responses would be:

1) If we expect people tomove to PostGIS 2.0, there current tables built
with AddGeometryColumn? should work as they did before. It would be
painful to have them alter their geometry columns to typmod. With that
said -- the postgresql catalog will be wrong for these geometries.

This is something that could be automated as part of an upgrade. A script
can be run to check the uniqueness of the geometry types within a table -
if they are unique then we can update the catalog to represent the correct
value, otherwise we set the typmod to be a generic GEOMETRY instead.

And also - if we're going to make people do things like a dump/reload
(which they will need with the new geometry format in 2.0) we might as
well do other horrible things as part of the upgrade.

2) For inheritance tables -- it is not unusual and I don't think bad
practice to have each child have a separate geometry type (though it
should have the same srid and dimension). typmod simply doesn't work for
this model.

Again, set the typmod to a generic GEOMETRY type but then add your own
constraints on your child tables. I would say that mixing things in this
way is an advanced level feature.

3) There are varying degrees -- e.g. I think for example Oracle doesn't
mind POLYGON/MULTIPOLYGON coexisting. Neither do ESRI Shapefiles. When you
have a polygon in must cases it is more efficient to keep it that way than
wrapping it in a multi wrapper. typmod doesn't work for this either.

This one is more tricky - if it were me, I would just use MULTIPOLYGONS
with one polygon for single shapes. When you say more efficient, what
exactly do you mean here?

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

1) Automation is not what I was worrying about. I was more worried about
speed.
For example converting a varchar(50) to say a varchar(1000) takes a
painful amount of time for a large table. OF course I may be over
estimating this. I think if Paul goes ahead with the typmod, I can test
with a 10 million record table converting to typmod to see just how
painful it is.

I really think we should avoid updating the catalogs directly. too much
has changed betweenn 8.4-9.1 that I wouldn't want to risk screwing it up.
Besides the PostgreSQL devs really frown on those changes.

2) Okay I can concede to that. It's a bit inconvenient than using
addgeometrycolumn but I agree it's a more advanced use case and rare at
that.

3) I think a lot of the speed issues we have addressed for this. In the
past it was significantly faster doing checks with polygons than
multipolygons even when a multipolygon had only one polygon. This is
probalby more an issue with third party tools than PostGIS.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

Mark,

AddGeometryColumn is an OGC standard but seems to not be mentioned at all
in the SQL/MM specs and in the OGC it does call it a table that needs
registration. Same for DropGeometryColumn.

The SQL/MM spec (seciton ISO/IEC CD 13249-3:200x() I am looking at
doesn't even have geometry_columns but talks about
ST_GEOMETRY_COLUMNS (which is a view (living in ST_Information_Schema)
"which lists the columns whose declared type is ST_Geometry
or one of its subtypes;" ). Thus my suggestion that our pure solution
that only looks at the system catalogs be called ST_Geometry_Columns and
that geometry_columns be a hybrid.

One additional note. Given the amount of back and forth we have had on
this topic, I think this one calls for an RFC of how exactly we propose to
change this. I think typmod is great and we should go ahead with that so
its really the question of how to manage the metadata. To me this is a
fundamental change in the way people operate and the way we will be
recommending people to operate so it needs more consideration and
documentation.

I also think we should bring this up to discussion in regular postgis
users group
to get a better population metric of its impact and people's thoughts on
the matter (particularly people managing viewers and other tools that use
postgis). I'm only guessing based on my personal use cases, but I'm sure
there are a lot more we haven't thought about.

strk also mentioned that INSPIRE would like to keep track of additional
information beyond what is allowed in geometry_columns and making this a
system catalog only query view will make that worse. True its a side
issue, but thought I would bring it up as a topic for discussion.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

Now i remember the use case why I have multipolygon/polygon. For one
project I am working on where we have our own flex renderer, its a pain to
output multipolygons especially since most of the records in the table are
singular polygons. I have 9,000,000 records of polygons/multipolygon for
example of which only 1000 are true multipolygons. Admittedly since we are
writing our own renderer, the registration issue in geometry_columns isn't
terribly important except when my client has to view these things like
Safe FME - as I recall he couldn't see the tables in his FME workbench
unless they were registered.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by mcayland):

I think that if we went as far as having a hybrid solution, it would just
cause even more chaos in the long run. As Paul mentions up-thread, do we
want to be stuck with an ugly hack forever?

For point 1, converting a varchar(50) to a varchar(1000) can be done
easily with a single catalog query because the internal representation
doesn't change. In the same way that setting a typmod for a mixed column
can be done in the same way because by changing from a sub-class to a
super-class, we can guarantee that all of the criteria can be met and so
we don't need to check every single row. We would have to visit every row
if going the other way, but I don't think that's the common use case.

For point 3, I think we would need to see which tools have these issues in
order to get a feel for whether or not this would be a real problem.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

I think both you are Paul overestimate the length of forever. To me
forever (in software terms) is at best 3 years. If you believe the
doomsday sayers, it will be like a week from now.

A view can be easily changed whenever we want really, heck that's the
point of having a view -- to hide the underlying complexity of your system
and change it when you don't like it anymore. What you are proposing
violates with fiddling with catalogs violates the PostgreSQL development
policy and is much harder to backout than what I am proposing.

Anyrate my point is we don't really need to make this decision quite just
yet. We want typmod, we are all in agreement with that, so we should go
ahead with that piece and test applications and various scenarios to know
which way to go with the second part.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by mcayland):

I don't think changing the catalogs is violating the PostgreSQL
development policy - for example, until reasonably recently the
operator/operator class definitions were all done by inserting/updating
the catalogs directly because the operator and operator class functions
did not contain sufficient functionality at the time.

Sure you can shoot yourself in the foot if you don't know what you're
doing with the catalogs, but I don't see much elevated risk performing an
upgrade that involves running a pre-packaged, test script.

I agree with you that we should probably spin this out into a separate
thread on postgis-users. If people are doing interesting things with their
geometry columns, then that's where we'll find out about it.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)
#944: typmod support for PostGIS geometry
-------------------------+--------------------------------------------------
Reporter: robe | Owner: pramsey
Type: enhancement | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: trunk
Keywords: |
-------------------------+--------------------------------------------------

Comment(by robe):

I just thought about another issue with this. It won't handle complex
views I don't think.

It will handle the simple view case of

SELECT ...geom
FROM sometable;

But I don't think it will handle

SELECT ST_Transform(geom,4326) As geom
FROM sometable;

Anyrate I'm going to push this to postgis-users since a similar topic came
up.

--
Ticket URL:
PostGIS
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
_______________________________________________
postgis-devel mailing list
postgis-
http://postgis.refractions.net/mailman/listinfo/postgis-devel
)