Josh Berkus wrote:
> Tom,
>
> > This is exactly the sort of argumentation that got the last proposal
> > shot down ;-). I see no reason that you can't do the namespacing and
> > security as well or better using the existing (and more standard) schema
> > feature. If there's something there that's not covered, what is it?
>
> a) When you have 1000's of procedures, it becomes very useful to have more
> than one level of namespacing. This is not an exaggeration; one project I
> looked at who decided not to convert from Oracle to PostgreSQL had over
> 100,000 procedures and functions. Lack of packages was their main reason
> for not switching. Schemas provide only *one* level of namespacing, unless
> we want to "improve" on the SQL standard and allow nested schemas.
>
> 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?
-- 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
