Handling PostGreSQL Schemas in DATA field

[marcjacquin]

In mappostgis.c the msPostGISBuildSQLSRID does take in account the schema when parsing the table name before calling find_srid.

char *strSRIDTemplate = "find_srid(,'%s','%s')" ignores the Postgresql schema, if the table name layerinfo->fromsource was parsed to find a schema.tablename that would help using multiple schemas and use schema.table in DATA field.

[marcjacquin]

Additional information : this occurs when the geometry_columns table is in the separate schema instead of being in the public schema.

[marcjacquin]

Tried to implement it on version 5.2.1 which different from 5.4.0. Assuming that the geometry_columns table is in the separate schema and PostGIS functions too, all the calls to PostGIS functions that use the schema.geometry must be preceded with the schema name (schema.force_2d() e.g.).

[adube]

A printscreen of the problem

[pramsey]

It sounds like there are two issues here,

• handling tables that are in alternate schemas
• handling the case where postgis itself is installed in an alternate schema

The first case needs to be done, and if it is broken, that's an oversight that needs fixing (btw, quick workaround, explicitly assign your SRID and UNIQUE key in the data statement, that way Mapserver doesn't need to look them up)

The second case is more problematic, since there's no slot in the current set-up to hold the information "where is my postgis installed". I'd suggest as a starting point, set the search path of the user you are using for mapserver connections to include the postgis installation schema and see how much better things get.

[pramsey]

Could you confirm whether your issue is tables in alternate schemas or postgis installs in alternate schemas? Ideally, a data dump and associated map file would speed resolution a great deal. Otherwise I have to build my own test cases, which takes my (oh so valuable) time.

[pramsey]

Closing this until reporter comes back to the table.