[postgis-devel] PSC Vote: set schema search_path for select functions

[Rémi Cura]

I personnaly would really prefer that all postgis matter is in a postgis
schema by default.
It is confusing and annoying that everything gets into public schema

For instance with postigs topology everything is in the topology schema.

Cheers,
Rémi-C

2015-03-14 5:53 GMT+01:00 Paragon Corporation <lr at pcorp.us>:

> I'm thinking of doing something somewhat controversial which I should
> probably get PSC vote on before I go thru the effort of putting it in and
> testing out.
>
> We've been getting a lot of complaints of this sort:
>
> http://trac.osgeo.org/postgis/ticket/3076
>
> http://trac.osgeo.org/postgis/ticket/2485
>
>
> With the rise of materialized views, postgres_fdw,  PostGIS raster,
> general
> database users (with more purist ways of organizing data starting to use
> PostGIS)  we are going to hear a lot more screams of this sort coming down
> the pike of the worst case being people not being able to restore their
> data
> without some workarounds.  I in fact helped a guy just last month and felt
> so bad I didn't charge him much for the consultation.  He was having
> problems restoring data from his production to his identical dev setup and
> spent hours scratching his head.
>
>
> So anyway explaining the issue.  This issue arises whenever we have
> functions in PostGIS that call other PostGIS functions or tables and people
> either put their data in a schema other than where they installed PostGIS
> or
> in case of postgres_fdw where schema is not as controllable.
>
> This is the case with a lot of the raster constraint functions, many of our
> ST_Distance functions, and ST_Transform to name the main ones that bite
> people.
>
> My proposition is to in these functions, set the function schema
> search_path
> to include the common schemas people decide to install PostGIS in.
> So for example for :
>
> ALTER FUNCTION st_distance(text, text) SET
> search_path=postgis,contrib,extensions,public;
>
> I would put this in a separate file to be included just so it doesn't mess
> up our postgis parsers and can be easily pulled out if we find the need to.
>
>
> This is a bit of a breaking change in that if people don't install PostGIS
> in one of the common schemas we assume they would, then functions will just
> not work for them since the Function search_path will override whatever
> search path they set.
>
> The above seems like a less bothersome issue than people not being able to
> restore their data without having a doctorate in PostGIS.
>
> Does anyone have an issue with this change?  I was going to put it in
> PostGIS 2.2 and then backport it to 2.1 after doing some more extensive
> tests.
>
>
> Thanks,
> Regina
>
>
>
>
>
>
>
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20150315/b6c049ae/attachment.html>