Re: autocommit vs TRUNCATE et al - Mailing list pgsql-hackers

From Tom Lane
Subject Re: autocommit vs TRUNCATE et al
Date
Msg-id 15638.1035265081@sss.pgh.pa.us
Whole thread Raw
In response to Re: autocommit vs TRUNCATE et al  (Joe Conway <mail@joeconway.com>)
Responses Re: autocommit vs TRUNCATE et al  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Joe Conway <mail@joeconway.com> writes:
> I just noticed that this afternoon's changes cause dblink's regression
> test to fail due to:

> CREATE OR REPLACE FUNCTION conditional_drop()
> [...]
>      IF FOUND THEN
>          DROP DATABASE regression_slave;
>      END IF;
> [...]
> ' LANGUAGE 'plpgsql';
> SELECT conditional_drop();

> I'm wondering what is the best alternative?

Well, the *best* alternative would be to make CREATE/DROP DATABASE
transaction-safe ;-).  I was speculating to myself earlier today about
how we might do that.  It seems like it's not that far out of reach:
we could make smgr's list of files-to-remove-at-xact-commit-or-abort
include whole database subdirectories.  But I'm not sure how that would
interact with upcoming features like tablespaces, so I don't want to
go off and implement it right now.

In the meantime, to tell you the truth, the cleanest way to handle the
dblink regression test would be to make it circularly connect to
database "regression".  I know this seems cheesy, but as long as the
software under test doesn't know that it's a connection-to-self, seems
like the test is perfectly good.  And it's surely easier to manage that
way.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Joe Conway
Date:
Subject: Re: autocommit vs TRUNCATE et al
Next
From: Joe Conway
Date:
Subject: Re: autocommit vs TRUNCATE et al