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 ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
