From: | "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | chris(at)hub(dot)org, pgsql-hackers(at)postgresql(dot)org, chris(at)pgsql(dot)com, geoff(at)pgsql(dot)com |
Subject: | Re: Schema boggle... |
Date: | 2003-11-05 22:02:58 |
Message-ID: | 20031105180054.K11434@ganymede.hub.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 5 Nov 2003, Tom Lane wrote:
> Chris Bowlby <excalibur(at)hub(dot)org> writes:
> > As you can see this is a nice, clean way to break down some datasets.
> > But, if I do:
>
> > set search_path to public, test_001, test_002;
>
> > I only get access to the tables in test_001 and public, the tables in
> > test_002 are not listed, and thus I do not see them on the screen while
> > doing a "\d".
>
> Well, sure. They are masked by the identically named tables in
> test_001. How else would you expect it to work?
List of relations
Schema | Name | Type | Owner
----------+-----------------------+----------+-----------
public | categories | table | 186_pgsql
public | categories_rec_id_seq | sequence | 186_pgsql
test_001 | table1 | table | 186_pgsql
test_002 | table1 | table | 186_pgsql
the uniqueness, I would have thought, woudl have been schema.name, not
just name ...
From | Date | Subject | |
---|---|---|---|
Next Message | Matthew T. O'Connor | 2003-11-05 22:06:40 | Re: Performance features the 4th |
Previous Message | Josh Berkus | 2003-11-05 21:58:34 | Re: Schema boggle... |