<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">I’d like to figure out what the long-term solution is before committing to the short-term hacks.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">Is it to make postgis non-relocateable and stick it into its own schema? The mechanics of having it relocatable seem intractable given the complexity of our machinery. Opinions on this very much welcome.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">P.</div> <div id="bloop_sign_1426435959155503104" class="bloop_sign">
<title></title>
<div>
<br>
</div>
-- <br>
Paul Ramsey<br>
http://cleverelephant.ca<div>http://postgis.net
</div>
<script type="application/ld+json">
{
"@context": "http://schema.org",
"@type": "em",
"name": "John Doe",
"jobTitle": "Graduate research assistant",
"affiliation": "University of Dreams",
"additionalName": "Johnny",
"url": "http://www.example.com",
"address": {
"@type": "PostalAddress",
"streetAddress": "1234 Peach Drive",
"addressLocality": "Wonderland",
"addressRegion": "Georgia"
}
}
</script>
</div> <br><p style="color:#000;">On March 14, 2015 at 6:38:38 PM, Paragon Corporation (<a href="mailto:lr@pcorp.us">lr@pcorp.us</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span><div lang="EN-US" link="blue" vlink="purple" xml:lang="EN-US"><div></div><div>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<title></title>
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">That
would be a long term solution, but unfortunately that would break
too many people's installs and cause an upgrade nightmare, so not
going to enforce that at least not in the short-term. This
proposal at least ensures people who choose to install in postgis
schema won't be screwed during database restore.</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Thanks,</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Regina</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span></p>
<p class="MsoNormal" style="margin-left:.5in"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b>
<span style="font-size:11.0pt;font-family:"Calibri",sans-serif">postgis-devel-bounces@lists.osgeo.org
[mailto:postgis-devel-bounces@lists.osgeo.org] <b>On Behalf Of</b>
Rémi Cura<br>
<b>Sent:</b> Saturday, March 14, 2015 8:31 PM<br>
<b>To:</b> PostGIS Development Discussion<br>
<b>Subject:</b> Re: [postgis-devel] PSC Vote: set schema
search_path for select functions</span></p>
<p class="MsoNormal" style="margin-left:.5in"> </p>
<div>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-left:.5in">I personnaly would
really prefer that all postgis matter is in a postgis schema by
default.</p>
</div>
<p class="MsoNormal" style="margin-left:.5in">It is confusing and
annoying that everything gets into public schema</p>
</div>
<p class="MsoNormal" style="margin-left:.5in"> </p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">For instance with
postigs topology everything is in the topology schema.</p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><br>
Cheers,</p>
</div>
<p class="MsoNormal" style="margin-left:.5in">Rémi-C</p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> </p>
<div>
<p class="MsoNormal" style="margin-left:.5in">2015-03-14 5:53
GMT+01:00 Paragon Corporation <<a href="mailto:lr@pcorp.us" target="_blank">lr@pcorp.us</a>>:</p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal" style="margin-left:.5in">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></p>
</blockquote>
</div>
<p class="MsoNormal" style="margin-left:.5in"> </p>
</div>
</div>
_______________________________________________
<br>postgis-devel mailing list
<br>postgis-devel@lists.osgeo.org
<br>http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel</div></div></span></blockquote></body></html>