AddGeometryColumn does not detect search_path properly

[kneufeld]

What steps will reproduce the problem?

1. CREATE SCHEMA tmp;
2. CREATE SCHMEA tmp2;
3. CREATE TABLE tmp2.foo2();
4. SET search_path to tmp, tmp2, public;
5. SELECT addgeometrycolumn('foo2','the_geom',3005,'POINT',2);

What is the expected output?

addgeometrycolumn

---

tmp2.foo2.the_geom SRID:3005 TYPE:POINT DIMS:2

What do you see instead? ERROR: relation 'tmp.foo2' does not exist

We should be using pg_catalog.pg_table_is_visible(oid) instead of current_schema to look for the schema name of the table.

[mcayland]

<i>(No comment was entered for this change.)</i>

[kneufeld]

QA appreciated.

A fix is still required for DropGeometryColumn, DropGeometryTable, and UpdateGeometrySRID.

[kneufeld]

<i>(No comment was entered for this change.)</i>

[robe]

Haven't tried running the code but on spot inspection I see a problem.

Looks like you also replaced GeometryType call with ST_GeometryType, but GeometryType returns something like 'POINT', 'POLYGON' etc. as I recall and ST_GeometryType returns 'ST_Point', 'ST_Polygon' etc. Isn't that a breaking change.

[kneufeld]

Ah. No, ST_GeometryType does not return prefix the geometry type with an 'ST_', but for some reason it does exclude many of the possible return types ('CURVEZ', 'SURFACEM', etc.) even though the specs do state in 7.2.8.1 'The SQL/MM ... ST_GeometryType... routine[s] shall be supported for all Geometry Types' (those listed in 7.1.3.3)

I updated the three column constraints to use the 'ST_' prefixed functions. I suppose the type constraint should remain as geometrytype() until ST_GeometryType gets updated to return valid types as per the specs.

[robe]

It does when I test it under 1.3.4 (though don't have my 1.4 around to test with). Though I always questioned if that was correct behavior.

Example -- SELECT ST_GeometryType('POINT(1 2)')

returns

ST_Point

[kneufeld]

Umm. Yup, you're correct, I misread my skim read of the function ... missed the concatenation at the end of the function.

In any case, I agree that this is not correct behaviour as it does not follow the specs.

[ke...@…]

​http://postgis.googlecode.com/issues/attachment?aid=1896010657424163462&name=addgeometrycolumn.patch

[kneufeld]

Small update to patch to keep the geometrytype() check constraint.

[ke...@…]

​http://postgis.googlecode.com/issues/attachment?aid=-6341491221572154800&name=addgeometrycolumn.patch