> 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
