Re: Understanding Schema's

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

In response to

Browse pgsql-general by date

  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