Joe Conway <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
