Re: search_path vs extensions - Mailing list pgsql-hackers

From David E. Wheeler
Subject Re: search_path vs extensions
Date
Msg-id AC6F2278-6CC2-4AE4-81B4-F4B28FD2EDB0@kineticode.com
Whole thread Raw
In response to Re: search_path vs extensions  (Greg Stark <stark@enterprisedb.com>)
List pgsql-hackers
On May 29, 2009, at 2:45 PM, Greg Stark wrote:

> 2) Normally programming languages do early binding so as soon as the
> code is parsed references are resolved. You can't later define a new
> function earlier in the search path and have it take over references
> that have were previously referring to some other function.

Not functions, but see method dispatch.

> Well I think the thinking is that if the extension author wants to
> hide some objects from the public he creates a schema for them and
> references them explicitly.

Agreed.

> If he pushes that private schema onto the search path he'll find any
> functions he calls -- admittedly not that common since we don't have
> any way to do callbacks, i suppose triggers on tables his code
> modifies counts though -- will have this private schema in its search
> path...

Yeah, it'd be nice to lexically scope such search_path modifications,  
such as for the duration of a function call.

> If we do want special handling it does seem to me that it would make
> sense to have some token like _private_ which the extension loading
> mechanism would automatically substitute for a unique schema name.
> Otherwise we're relying on extension authors to come up with unique
> names.

Agreed.

Best,

David



pgsql-hackers by date:

Previous
From: "David E. Wheeler"
Date:
Subject: Re: search_path vs extensions
Next
From: "David E. Wheeler"
Date:
Subject: Re: search_path improvements WAS: search_path vs extensions