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

[Paragon Corporation]

>> 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.

> Hmmmm I'm not convinced this is the right thing to do here. There are some
notes in section 35.15 of the PostgreSQL documentation relating to
extensions which cover relocation, but

 > not for this exact case. I'd say it's probably worth starting a thread on
pgsql-hackers to explore the options available before committing to one
particular approach, and even then it may > be that some historical users
will still need to make manual changes.
> ATB,

> Mark.

Mark,

Bringing this issue up in pgsql-hackers sounds like a great idea as I very
well may have missed something.  What I had hoped is that eventually
PostgreSQL extension machinery would be smart enough to just add the search
path where the extension is installed to the functions since why wouldn't an
extension want to naturally want to call other functions in the extension.
That has not happened, and perhaps there is a reason why it can't.

Understand though that the main issue I am talking about is that people at
this point are unable to restore their data and that to me is a pretty
serious problem. The only thing that would make this a short-term hack is if
the PostgreSQL project would change to automatically take into consideration
the schema an extension is installed in.  Even if you specify it as
non-relocatable it just prevents people from installing it in any schema
they want. 

The whole non-relocatability long term thing people talk about 

1) I'm not convinced is that helpful 
2) Is very painful in terms of re-architecting and testing
3) Is going to be painful for users upgrading who by default just install
postgis in public -- which I would guess is about 80% or more of the PostGIS
user base (The 20% I think would be okay would be Django and ruby I think
automatically install postgis in postgis schema so not sure what percentage
of folks use that and have it install PostGIS for them and DBA like people
who are paranoid about neatness )..  I don't want to make a 20% problem an
80% problem.

Thanks,
Regina