From: | Jacqui Caren-home <jacqui(dot)caren(at)ntlworld(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Understanding Schema's |
Date: | 2010-12-15 13:24:45 |
Message-ID: | 4D08C19D.2070101@ntlworld.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 15/12/2010 00:20, Carlos Mennens wrote:
> Why would anyone in a random scenario want to have independent
> schema's to cross query? I'm just trying to see how this would be
> useful in any scenario.
One very real example :-)
When migrating from say mysql to PgSQL it is possible to populate a "mygration" schema with functions, domains etc to allow (some)
native mysql SQL to run within PgSQL.
However such code does not give the best performance so the next step is to identify the mysql code in use (via notifies?) then replace with new
(hopefully more portable) SQL.
Once you stop getting notifies, you remove the mygration schema from the search path and run your test suite once more.
If all passes you know you are now mysql free :-)
---------------------------------------
When developing databases we often end up with hundreds of tables many of which are feature/application
specific with a core of common tables. schemas are not just handy but essential as by setting the search
path we define what an application can "see". not perfect and not a security feature but "handy"
especialy for developers.
One example is a a3c schema used for authentication, authorization and access control. My template schema
provides a generate users, roles, rights model for use within apps.
Jacqui
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2010-12-15 14:13:29 | Re: Linux: PAE or x64 |
Previous Message | Filip Rembiałkowski | 2010-12-15 13:23:16 | Re: Changing WAL Directory in Postgres |