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

[Paragon Corporation]

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