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

[Paul Ramsey]

I’m much happier with this, which allows a solution without the hacky “guess all the variants” stuff. Seems like a suitable way forward: most folks won’t notice a thing, and those who (foolishly) install somewhere other than public (why did we have the EXTENSION thing, if not to allow us to dump thing cleanly into public?) to recover from the error of their ways.

P 


--  
http://postgis.net  
http://cleverelephant.ca


On March 16, 2015 at 3:08:39 PM, Paragon Corporation (lr at pcorp.us) wrote:
> Strk,
>  
> I think that is a pretty painful idea below, and definitely not something we can do in a  
> micro release. It will require quite a bit of invasiveness of our code and a painful restore  
> process for users and if we do that, there will be no looking back.
>  
> That said -- revisiting the search path idea -- I missed something in one of Tom's notes  
> (which I think Mark alluded to but I can't find it in the manual specifically)
>  
>  
> http://www.postgresql.org/message-id/13445.1420839491@sss.pgh.pa.us
>  
> In it he said this:
>  
> "You can do it for relocatable-at-install-time extensions, as suggested in
> the manual:
>  
> CREATE FUNCTION ... SET search_path = @extschema@ ... "
>  
>  
> Which is along the train of thought I had except the key differences with his is using the  
> @extchema@ variable which is available during the create extension (and I think also  
> the ALTER EXTENSION process instead of hard-coding an assumption of schema's where  
> postgis is installed. I also wanted to use
>  
> ALTER FUNCTION instead of putting it as part of the CREATE FUNCTION definition. Since  
> with ALTER it can be easily segregated from the CREATE part.
>  
> I'm not sure if ALTER will work though (e.g. if that setting would work ). I'm guessing  
> it would since it is part of the extension install script and CREATE EXTENSION/ALTER  
> EXTENSION would just call whatever is in the script.
>  
> Building the search_path in the function definition, takes care of the hijacking issue  
> I think you were concerned about for the most part and is less invasive than what you are  
> proposing
> And has the benefit of allowing people to install PostGIS where they want. Which who knows  
> some third-party tool might have hard-coded public in their code and we'd be unintentionally  
> breaking that code.
>  
>  
> Thanks,
> Regina
>  
>  
> -----Original Message-----
> From: postgis-devel-bounces at lists.osgeo.org [mailto:postgis-devel-bounces at lists.osgeo.org]  
> On Behalf Of Sandro Santilli
> Sent: Monday, March 16, 2015 5:33 AM
> To: PostGIS Development Discussion
> Subject: Re: [postgis-devel] PSC Vote: set schema search_path for select functions  
>  
> On Sun, Mar 15, 2015 at 02:13:24PM -0400, Paragon Corporation wrote:
> > I actually don't care so much about enforcing non-relocatability. The only benefit  
> of doing that is then we can have a single schema to set the search_path and/or we can schema  
> qualify all our PostGIS function calls which is a big exercise in monotonous labor. I'd  
> still go with just setting search_path for each function since we can automate that and  
> will be valuable if we DO in future decide to enforce PostGIS installed in schema postgis.  
>  
> The other benefit is we can trust PostGIS code more, in that it would not allow for search_path  
> based hijacking. I think it's a worth move.
>  
> > The main issue is that whether we go down the path of making it non-relocatable or not,  
> we are still going to have to set the search_path of each function that calls other functions  
> and tables or schema qualify all our calls.
>  
> We don't need to tweak search_path if the functions and view implementations fully qualify  
> the name of accessed objects.
>  
> > For example let's hypothesize we were to enforce postgis be always installed in postgis  
> schema. If someone puts their data in another schema say public, they still won't be able  
> to restore their data cleanly if they have raster constraints or use ST_Distance (and  
> other functions that call other PostGIS functions) functions in their materialized  
> views or use postgres_fdw and use distance functions.
>  
> That's a job for postgis_restore.pl, we succeeded in converting SRIDs already, and  
> injecting ST_ prefix, no problem in doing more, IMHO.
>  
> --strk;
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel
>  
>  
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel
>