Re: Schema boggle...

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: chris(at)hub(dot)org
Cc: pgsql-hackers(at)postgresql(dot)org, scrappy(at)hub(dot)org, chris(at)pgsql(dot)com, geoff(at)pgsql(dot)com
Subject: Re: Schema boggle...
Date: 2003-11-05 21:34:01
Message-ID: 13385.1068068041@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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?

> 2. Issue 2, is more a SQL issue then anything, but I'd like to be able
> to do something to the affect of:

> SELECT * FROM test_*.test_domains ORDER BY domain_name;

I can't see trying to support this at the SQL level. You might consider
making a plpgsql function that constructs a UNION ALL query listing all
the proper schemas and then EXECUTEs it on-the-fly.

Another possible solution is to make all the individual tables be
inheritance children of a master table. Then selecting from the master
would work (and would be equivalent to the UNION performance-wise, I
think).

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2003-11-05 21:48:48 Changes to Contributor List
Previous Message Manfred Spraul 2003-11-05 21:30:16 Re: Performance features the 4th