Tom Lane wrote:
I think the "least bad" is the first option -- disallow TRUNCATE unless autocommit is on. With the second option, people would be caught by surprise at precisely the worst possible moment. Better to make them take the extra step.There are a number of statements, such as TRUNCATE TABLE, that refuse to run in a transaction block because they perform actions that can't be rolled back later.These statements currently do not look at autocommit, which means that if autocommit is off, their tests will succeed ... but then a transaction block is started anyway, defeating the point of the test. We could fix these statements to fail if autocommit is off, which means that you could not use them at all except by setting autocommit on. Ugh. Or we could fix them to force an autocommit. Which would mean that these "dangerous" statements would become even more dangerous, since that's exactly the behavior a person using autocommit-off would not expect. Also ugh. Anyone see a way out of this catch-22? If not, which is the least bad alternative?
Joe
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
