Andres Freund <and...@anarazel.de> writes: > On Tuesday 30 November 2010 20:24:52 Marko Tiikkaja wrote: >> I don't buy the argument either; why would you put a LIMIT there and >> delete one row by accident when you could put a BEGIN; in front and not >> do any damage at all? > Because the delete of the whole table may take awfully long?
Then you just C-c and that's your ROLLBACK. Been there, seen that (a developer came to me sweating over maybe-lost data — his chance was that forgetting the WHERE clause, it did take long enough for him to C-c by reflex, the oops moment). But more to the point, I don't see that we're this much on the policy side of things rather than on the mechanism side. This feature has real appealing usages (cheap work queues, anti-deadlock, huge data purges with no production locking — you do that in little steps in a loop). To summarize, people that are arguing against are saying they will not themselves put time on the feature more than anything else, I think. I don't see us refusing a good implementation on the grounds that misuse is possible. After all, advisory locks are session based, to name another great foot gun. If you don't think it's big enough, think about web environments and pgbouncer in transaction pooling mode. Loads of fun. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
