On 8.0 and below, you can't use a simple ALTER TABLE to do this, but you
can modify pg_class. However, this may or may not be safe. In 8.1 you
can do ALTER TABLE name SET SCHEMA blah.
decibel=# create table public.t(t text);
CREATE TABLE
decibel=# alter table public.t rename to decibel.t;
ERROR: syntax error at or near "." at character 39
LINE 1: alter table public.t rename to decibel.t;
^
decibel=# select oid,* from pg_namespace where nspname in ('public','decibel');
oid | nspname | nspowner | nspacl
-------+---------+----------+-------------------------------------
2200 | public | 1 | {postgres=UC/postgres,=UC/postgres}
18640 | decibel | 100 |
(2 rows)
decibel=# update pg_class set relnamespace=18640 where relnamespace=2200 and relname='t';
UPDATE 1
decibel=# \d decibel.t
Table "decibel.t"
Column | Type | Modifiers
--------+------+-----------
t | text |
decibel=# \d public.t
Did not find any relation named "public.t".
decibel=#
On Wed, Oct 19, 2005 at 11:11:12PM +0100, Chris Jewell wrote:
> Hi,
>
> With an ever increasing number of tables being added to our research
> database, we have come to the conclusion that we need to confine
> individual users to private schemas instead of everybody creating their
> tables in the default public schema. In order to move the tables, I
> have used a CREATE TABLE <privateschema>.<tablename> AS SELECT * FROM
> public.<tablename>; command on each private table. This worked fine.
> However, when it came to DROPping the old tables from the public schema,
> I had trouble with user's views that were dependent on these tables. I
> don't want to use the CASCADE attribute as I don't want to erase all my
> users' views.
>
> Thus, my question is: can I migrate the views such that they point to
> the new tables in the users' schemata, and/or how do I drop the public
> schema tables without dropping the users' views?
>
> Thanks,
>
> Chris
>
> --
> --
> Chris Jewell, BSc(Hons), BVSc, MRCVS
> Dept of Maths and Statistics
> Fylde College
> Lancaster University
> Lancaster
> Lancs
> LA1 4YF
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
>
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461