Jim C. Nasby wrote:
I don't believe types allow for internal-only methods. I seem to recallDo Oracle packages support internal only functions? If they do, then I agree, that's a feature that the SQL standard doesn't have.
other limitations on what types could do as opposed to packages. Of
course, we need not restrict ourselves in such a manner.
If used as a package, i.e. only containing static methods, you don't need to use the type in relation to anything. It's simply a namespace. If used with a temporary table, you get a very neat, standardized, cross-language way of managing session data.Types are not used nearly as much as packages (this is an issue if we care about enabling Oracle users to migrate).
Types generally force you to use them in relation to some database
object. Packages have no such restriction.
Don't get me wrong, I think supporting more powerful types would be aI see this differently. A full implementation of the SQL-standard for UDT's will allow abstract types, inheritance, method overloading, etc. It quickly becomes far more flexible then Oracle packages. A full implementation is of course beyond the scope for what's needed to accommodate the needs of those who use packages but a simple implementation is extendable within the scope of the standard.
welcome addition, but I don't think they can be as flexable as packages.
The good news is that they should both be able to use the sameRight. Given a good implementation of types, packages would be easy to implement. The other way around would not be possible. A package is a very restricted type that contains static methods only. Possibly with the extension of some kind of method/attribute visibility.
underlying framework. Types are afterall just a specialized
implementation of packages.
So do we need "internal only" functions although they are not covered by the SQL-standard? If the answer is no, then IMO we should follow the standard and use types, not packages. If the answer is yes, then the SQL-standard is not enough. Should we then use packages or simply introduce the keyword PRIVATE on methods of a type? Personally, I'd go for the latter and then, if necessary, build packages on top of that in for the benefit of Oracle users who wants to migrate. A fully fledged type system will ease Oracle migration too since Oracle already has this.
Regards, Thomas Hallgren
---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
