From: | Fernando Nasser <fnasser(at)redhat(dot)com> |
---|---|
To: | Rod Taylor <rbt(at)rbt(dot)ca> |
Cc: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, Joe Conway <mail(at)joeconway(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: ALTER TABLE schema SCHEMA TO new_schema? |
Date: | 2002-12-03 16:20:22 |
Message-ID: | 3DECD9C6.4040106@redhat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Rod Taylor wrote:
>>Why just restrict them to moving tables? What if someone wants to move a
>>function or an aggregate to another schema?
>>
>>What if they want to copy it?
>
>
> Copying might be tricky, but I'd be happy to help with moving everything
> else around. Though I don't think sequences can move (until we can
> properly track their dependencies) but everything else should be able
> to.
>
> Copy is another story all together. But I'd like a
>
> CREATE SCHEMA ... AS COPY <schemaname>;
>
Wouldn't it be better to use pg_dump/pg_restore for that?
If we could ask for just oen/some of the non-system schemas to be dumped
it would be easy to restore it as another or even move it to another
database. And one could dump only the schema or schema+data, as needed.
Of course, dependencies would have to be handled as objects can refer to
objects in other schemas.
--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: fnasser(at)redhat(dot)com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2002-12-03 16:21:04 | Re: 7.3 -> pg_atoi: zero-length string |
Previous Message | Magnus Naeslund(f) | 2002-12-03 16:19:37 | Re: Backend crash with tsearch |