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.
--
--Josh
Josh Berkus
Aglio Database Solutions
San Francisco
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
