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


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to