> DB2 propose using schemas instead packages
>
> https://www.ibm.com/developerworks/data/library/techarticle/dm-0711zubiri/ [https://www.ibm.com/developerworks/data/library/techarticle/dm-0711zubiri/] That article by Adriana is 6 years ago and was written actually while we implemented MODULE’s for DB2 9.7. So yes, when you don’t have modules, schemata are the way to go in the same way as when all you have is a hammer everything is a nail. We considered MODULEs an absolute must to get functional equivalency to Oracle PL/SQL packages. Also they wouldn’t take up so much space in the standard if they would be deemed to provide no function... > Now I am working with Oracle application - and I try to understand to Oracle
> developers - often pattern is using "Oracle schema" as database - and then
> the packages has sense. But there is not a mapping "Oracle schema" =
> "PostgreSQL schema" - and packages is a redundant concept in Postgres (and
> in all db, where the schema are like namaspace - MSSQL, DB2, MySQL). I have never heard the claim that database in Oracle matches schema in other DBMS. In my experience Oracle is well in line on the schema front with the exception of the one-to-one relationship between schema and user.
The database-is-really-a-schema mapping is something we (at DB2) traditionally associated with Sybase and SQL Server migrations where we saw plenty of small databases with cross database queries.
Having said all that I think schemata are quite powerful in Postgres, not least because of the clean usage of search_path for all object resolution and schema being independent of user. They get us a fair ways. The main gap remains the inability to do any sort of nesting. To have two “package-like-things” with the same name. I’m not going to repeat myself on that one and bore everyone. My thinking on modules is someone reflected here: https://www.ibm.com/developerworks/community/blogs/SQLTips4DB2LUW/entry/module?lang=en
Cheers Serge