Re: Is there a way around function search_path killing SQL function inlining? - and backup / restore issue

>> On 3/10/16 3:29 PM, Regina Obe wrote:
>> Take for example, I have tiger geocoder which relies on fuzzystrmatch. I have no idea where someone installs fuzzystrmatch so I can't schema qualify those calls. I use that dependent function to use to build an index on tables.

> This is something I've thought about as well, and I think the real problem is search_path just isn't the right way to handle this. I think there needs to be some way to definitively reference something that's part of an extension; a method
> that doesn't depend on whatever schema the extension happens to be installed in.
--
> Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com

I like that idea a lot though that sounds like something that requires a lot more work. In the long run it would be good though especially since I expect more and more extensions will rely on each other.

I have similar concerns with pgRouting which I am a member of dev team too, and pgRouting can't schema qualify any of the PostGIS calls because they have no idea where PostGIS is installed and the extension model as it stands
doesn't have provisions for referencing dependent extension locations. That hasn't been a major issue yet since pgRouting doesn't build functions that wrap PostGIS for indexing etc. it is however more of a future concern and is a concern for people who build materialized views using pgRouting functions since all of those use PostGIS heavily.

There is even if we do that the case of people just building their own functions untop of other things. I guess that one is not as much of a concern since they would generally know where their dependent functions are installed and can schema qualify.

Thanks,
Regina