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

From Joe Conway
Subject Re: autocommit vs TRUNCATE et al
Date
Msg-id 3DB4E156.8090701@joeconway.com
Whole thread Raw
In response to autocommit vs TRUNCATE et al  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: autocommit vs TRUNCATE et al  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:> We can go with the auto-COMMIT idea for statements that are invoked at> the outer interactive level,
butthat 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'llneed 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



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: BTree free pages again
Next
From: Tom Lane
Date:
Subject: Re: autocommit vs TRUNCATE et al