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 Josh describes here are excellent features but IMHO, the Oracle
PACKAGE concept is an abomination that should have been left out. The
reason I say this is that Oracle also provide the ability to create user
defined types that have methods. Both instance and static methods can be
created.
In Oracle you can use the syntax:
<schema>.<package>.<function>()
but you can just as well use the syntax:
<schema>.<type>.<static method>()
Why do you need both? If PostgreSQL is going to add new nice features
that enables better namespace handling and global variables, take a look
at Oracles UDT's with static and instance methods. Only thing that I'm
not sure is there is static variables. If it's missing, we could add
that easilly and give them the same life-span as the session.
A UDT can be exchanged seamlessly across PL's so it would become a
really elegant solution for session variables.
Regards,
Thomas Hallgren
