Ok, ok, correctness is a little bit more important than speed, i guess...
Regarding the speed of acs_object.name(): It is nice that it runs fast on your machine, but i don't know many million objects your system is holding and how many concurrent page requests your system does have.... Under load a system has to serve every page as fast as possible and i think i made it pretty clear that the invocation of pl/sql procs for every object to be displayed in a possible long object list (yes, normally a long list should be split on several pages, but still...) just has to be way slower than my proposed approach. That doesn't mean that acs_object.name() should not even be used to get the names of a limited number of objects. I'm just saying that this proc is one of the ad inventions that seemed nice on first sight, but if you really think about it and really try to use it in a huge system then you realize how flawed that approach is.
Regarding migration: Yes, i will make sure that migration scripts for the major packages will be written (anyone here for help?).
If you already agree that adding a name column to acs_objects (or a second table as i suggested to not blow up acs_objects unnecessarily since we don't need these infos for every single acs_object) makes some sense, then why not also adding at least package_id if not state, overview and overview_html_p?
