<div dir="ltr"><div><div><div>I personnaly would really prefer that all postgis matter is in a postgis schema by default.<br></div>It is confusing and annoying that everything gets into public schema<br></div><br></div><div>For instance with postigs topology everything is in the topology schema.<br></div><div><br>Cheers,<br></div>Rémi-C<br></div><div class="gmail_extra"><br><div class="gmail_quote">2015-03-14 5:53 GMT+01:00 Paragon Corporation <span dir="ltr"><<a href="mailto:lr@pcorp.us" target="_blank">lr@pcorp.us</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm thinking of doing something somewhat controversial which I should<br>
probably get PSC vote on before I go thru the effort of putting it in and<br>
testing out.<br>
<br>
We've been getting a lot of complaints of this sort:<br>
<br>
<a href="http://trac.osgeo.org/postgis/ticket/3076" target="_blank">http://trac.osgeo.org/postgis/ticket/3076</a><br>
<br>
<a href="http://trac.osgeo.org/postgis/ticket/2485" target="_blank">http://trac.osgeo.org/postgis/ticket/2485</a><br>
<br>
<br>
With the rise of materialized views, postgres_fdw,  PostGIS raster,  general<br>
database users (with more purist ways of organizing data starting to use<br>
PostGIS)  we are going to hear a lot more screams of this sort coming down<br>
the pike of the worst case being people not being able to restore their data<br>
without some workarounds.  I in fact helped a guy just last month and felt<br>
so bad I didn't charge him much for the consultation.  He was having<br>
problems restoring data from his production to his identical dev setup and<br>
spent hours scratching his head.<br>
<br>
<br>
So anyway explaining the issue.  This issue arises whenever we have<br>
functions in PostGIS that call other PostGIS functions or tables and people<br>
either put their data in a schema other than where they installed PostGIS or<br>
in case of postgres_fdw where schema is not as controllable.<br>
<br>
This is the case with a lot of the raster constraint functions, many of our<br>
ST_Distance functions, and ST_Transform to name the main ones that bite<br>
people.<br>
<br>
My proposition is to in these functions, set the function schema search_path<br>
to include the common schemas people decide to install PostGIS in.<br>
So for example for :<br>
<br>
ALTER FUNCTION st_distance(text, text) SET<br>
search_path=postgis,contrib,extensions,public;<br>
<br>
I would put this in a separate file to be included just so it doesn't mess<br>
up our postgis parsers and can be easily pulled out if we find the need to.<br>
<br>
<br>
This is a bit of a breaking change in that if people don't install PostGIS<br>
in one of the common schemas we assume they would, then functions will just<br>
not work for them since the Function search_path will override whatever<br>
search path they set.<br>
<br>
The above seems like a less bothersome issue than people not being able to<br>
restore their data without having a doctorate in PostGIS.<br>
<br>
Does anyone have an issue with this change?  I was going to put it in<br>
PostGIS 2.2 and then backport it to 2.1 after doing some more extensive<br>
tests.<br>
<br>
<br>
Thanks,<br>
Regina<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org">postgis-devel@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel" target="_blank">http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel</a><br>
</blockquote></div><br></div>