Josh Berkus wrote:
> 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 ...
Agreed, but saying we are going to just go out and implement everything
Oracle packages have just because they have them isn't likely to happen
for PostgreSQL. We need a list of things that need to be added, and how
our existing functionality will be modified to make them available.
Just saying "we need Oracle packages" doesn't make it happen. I have
followed the discussion and I still don't have a clear idea of the exact
additions that people want, and without that, nothing is likely to
happen. I don't even have something for the TODO list at this point.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073