Skip site navigation (1) Skip section navigation (2)

Re: Naive schema questions

From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: Rory Campbell-Lange <rory(at)campbell-lange(dot)net>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>,Nick Barr <nicky(at)chuckie(dot)co(dot)uk>,Postgresql General List <pgsql-general(at)postgresql(dot)org>
Subject: Re: Naive schema questions
Date: 2004-05-27 22:32:09
Message-ID: 40B66C69.6070300@Yahoo.com (view raw or flat)
Thread:
Lists: pgsql-general
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
> work?
> 
> I just did this which is useful anyway:
> schematest=> SELECT 
>             (select count(id) from b.messages) 
>             + 
>             (select count(id) from a.messages);
>  ?column? 
>  ----------
>          5
>          (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.


Jan

> 
>     this_schema, info_schema, public_schema
> 
> Thanks very much for the information.
> 
> Kind regards,
> Rory


-- 
#======================================================================#
# 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 GDate: 2004-05-28 02:27:07
Subject: Re: PostgreSQL Logs
Previous:From: Chris BrowneDate: 2004-05-27 22:13:43
Subject: Re: pg_restore quick question

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group