Re: search_path vs extensions

On Fri, May 29, 2009 at 10:26 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> This sounds quite horrid to me.  The way programming languages solve
> this problem is they have a flag that either makes certain names not
> visible from other namespaces, or they provide explicit control over
> which names get exported.

There are two factors which distinguish this situation from most
programming languages:

1) Hopefully these languages you're thinking of are lexically scoped.
So the search path in effect when the objects are defined decide which
other objects they reference. In Postgres in many cases we're
effectively dynamically scoped. If someone calls us with another
search path we'll pick up other objects we weren't expecting.

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.

> Requiring the extension author to split up
> the objects between two different hard-coded namespaces with schema
> qualifications on every reference sounds like an unmanageable mess.

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.

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

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.

--
greg