Re: [HACKERS] autocommit vs TRUNCATE et al

[Joe Conway]

Tom Lane wrote:
> We can go with the auto-COMMIT idea for statements that are invoked at
> the outer interactive level, but that doesn't work for stuff invoked
> inside a function. I think we need to forbid these statements inside
> functions, too. We already have that for VACUUM, because of its
> internal commits causing problems for functions, but we'll need to
> extend it to all of them.
>
> Just FYI, the statements involved are
> VACUUM
> TRUNCATE TABLE
> CREATE/DROP DATABASE

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? Should we simply do a "DROP DATABASE regression_slave;" and have the expected results include the 'database "regression_slave" does not exist'? In this case there would be an expected failure whenever the regression test was run more than once.

Joe


---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html