Bruce,
> > b) Schemas do not provide us with any way of limiting the scope of
> > functions and persistent variables. With packages, you would want:
> > 1. functions which can only be called internally to the package
> > 2. variables which are only visible inside the package
> > 3. functions which can only be called as part of the package (thus
> > utilizing the initialization and internal variables) and not on their
> > own.
>
> What if we defined functions to look in their own schemas for functions
> they call, then use the search_path, rather than using the search path
> first?
That really doesn't address the desired functionality. For example, I could
have a package whose initialization function involves some security checks,
and then the package's "methods" (internal functions) would access the
variables set by the security check function ... but those variables would
NOT be available to the user or modifiable by them.
I know the need for this is probably hypothetical to a lot of -hackers, but
it's pretty common programming in the Oracle PL/SQL world.
Of course, if there's something in SQL2003 that supports this, it would be
really keen to know it ...
--
--Josh
Josh Berkus
Aglio Database Solutions
San Francisco
