Add safety check for raster support to be in same schema as postgis

[strk]

Regina reported that raster and core should be in the same schema or bad things can happen. This ticket is to add a safety check in raster enabler script to make sure this is the case.

Regina it would be great to have an example of such bad thing, and we should make sure that non-extension load doesn't suffer form these bad things either (setting search_path for each installed function?)

[strk]

I just tested and it is indeed possible to install core in a schema and raster in another, with current scripts loading. What bad things can happen is not clear to me but maybe Regina can help with that part

[robe]

strk,

In PostGIS 2.3, everything was schema qualified to make dump and restore easy.

Since raster is part of postgis, I schema qualified all the PostGIS calls in it.

So if you install postgis say in schema called postgis;

and install postgis_raster in schema postgis_raster. All calls to postgis functions in your raster extension would be pointing at postgis_raster. It will not find the functions and well error out.

Take a look at:

https://git.osgeo.org/gogs/postgis/postgis/src/svn-trunk/raster/rt_pg/rtpostgis.sql.in#L5767

CREATE OR REPLACE FUNCTION raster_overlap(raster, raster)
    RETURNS bool
    AS 'select $1::geometry OPERATOR(@extschema@.&&) $2::geometry'
    LANGUAGE 'sql' IMMUTABLE STRICT _PARALLEL;

Granted a lot of places I missed. So any way all your raster indexes will be broken.

[strk]

But @schema@. is stripped off when generating the extension-less script, so the problem is only with extension. Do we want to make the two versions comparable when it comes to security, by maybe setting search_path against each installed function so it matches the schema of installation ?

Then we can threat both cases the same and introduce the safety check ensuring that the same schema of PostGIS is used to also load raster… (I'm not sure if any user would currently be installing raster in a different directory).

Or we could accept installing raster in any schema *but* set the search_path to be sure it includes the schema in which postgis is loaded ?

[robe]

Setting search_path against each installed function breaks sql inlining and a whole bunch of other things too unpredicatable to guess.

Remember that was what I tried and it slowed some functions to a crawl. I brought it up on hackers mailing list.

​https://www.postgresql.org/message-id/flat/CA%2BTgmob_WSEo1xNKHz6xZB4NLGfwAa9TTsf4_edA7zJtOXbzjQ%40mail.gmail.com#CA+Tgmob_WSEo1xNKHz6xZB4NLGfwAa9TTsf4_edA7zJtOXbzjQ@mail.gmail.com

So it needs to be hard-coded until PostgreSQL comes up with a solution.

[strk]

In 15938:

Forbid creating raster support objects in a schema != PostGIS one

Fixes #3893

[strk]

See how you like r15938 - I listed it as a breaking change because people might be installing raster in a different schema, at the moment, relying on search_path to eventually find PostGIS.

Doing the search_path setting ourselves would still be nice but seems to be worth another ticket (to remove the limitation of same-schema).

[robe]

Looks fine as mentioned us handling the search_path wouldn't help much because of the massive adoption of things like Foreign Tables and Materialized Views that ignore search_paths and the fact that trying to add as a definition of function the search_path in many cases causes the function to grind to a crawl in speed.

[strk]

thanks for review. The only grief I have is that in the non-extension scenario it really makes no difference where postgis raster objects are created, as the full-qualification of postgis functions is not there. I don't like the difference between extension and non-extension setups, basically. One is affected by search path and the other is not. But I guess this discussion does not belong here.