On 5/27/2004 6:03 PM, Rory Campbell-Lange wrote:
> Just a question on this, Jan. Would one expect UNIONS for this sort of
> I just did this which is useful anyway:
> schematest=> SELECT
> (select count(id) from b.messages)
> (select count(id) from a.messages);
> (1 row)
> I see the horizons expanding! Common data (I often have an 'info' table)
> can be shared between schemas. I think my search_patch might go:
You can mix those in queries however you want. They are just namespaces
with some additional security (even if you grant public access to an
object inside a schema, one still needs access to the schema itself).
The search path let's you hide one schemas objects behind another ones
by chosing the order. You can use qualified or unqualified names and
different search path's where one or the other makes sense in your
application- and data-design. After all, all the objects reside in the
same database and all access is covered by the same transaction.
The problem with expanded horizons is that one has more possibilities to
screw it up at the same time he get's more flexibility. Well used, this
is a powerfull feature. Poorly applied and inconsistently used it can
become a maintenance nightmare.
> this_schema, info_schema, public_schema
> Thanks very much for the information.
> Kind regards,
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #
In response to
pgsql-general by date
|Next:||From: Mike G||Date: 2004-05-28 02:27:07|
|Subject: Re: PostgreSQL Logs|
|Previous:||From: Chris Browne||Date: 2004-05-27 22:13:43|
|Subject: Re: pg_restore quick question|