On 5/23/2010 9:55 AM, David Fetter wrote:
> On Mon, May 17, 2010 at 02:58:01PM -0400, Steve Singer wrote:
>> Gurjeet Singh wrote:
>> 
>> > The doc-patch does make it more clear, but I don't think DROP
>> > SCHEMA _slony_cluster_name CASCADE is something I'd like to do
>> > with my running Slony replication. A cleaner way would be more
>> > desirable.
>> 
>> Another option you have is to restore the dump that you create of
>> your pgbench schema to another database(a new one).  When you
>> restore the CREATE TRIGGER statements will fail because the slony
>> stored procedures won't exist in your new database.   This should
>> leave you with your database - any slony stuff.  (I agree having to
>> put up with 'errors' during the restore or make a second copy of the
>> database just to do 'DROP SCHEMA' are both less than ideal
>> solutions)
> 
> Would it help if some future version of pg_dump had some option to the
> effect of, "leave out the following objects and everything that
> depends on them?"

That would certainly help and it is a more general use case, not 
something specific to Slony. If you have this

> create schema s1;
> create schema s2;
> create table s1.t1 (id integer primary key, data text);
> create table s2.t2 (id integer primary key, id1 integer references s1.t1 (id));

and then do a pg_dump -n s2, your dump will still contain

> --
> -- Name: t2_id1_fkey; Type: FK CONSTRAINT; Schema: s2; Owner: -
> --
> 
> ALTER TABLE ONLY t2
>     ADD CONSTRAINT t2_id1_fkey FOREIGN KEY (id1) REFERENCES s1.t1(id);

Fortunately, the foreign key in the dump is separated out so that the 
CREATE TABLE still succeeds, but you get an error message here as well.


Jan

-- 
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin