Re: autocommit vs TRUNCATE et al

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: autocommit vs TRUNCATE et al
Дата
Msg-id 15638.1035265081@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: autocommit vs TRUNCATE et al  (Joe Conway <mail@joeconway.com>)
Ответы Re: autocommit vs TRUNCATE et al  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Joe Conway
Дата:
Сообщение: Re: autocommit vs TRUNCATE et al
Следующее
От: Joe Conway
Дата:
Сообщение: Re: autocommit vs TRUNCATE et al