On Tue, Jul 03, 2018 at 01:06:31AM +0000, Yotsunaga, Naoki wrote: >> I'd rather spend effort making the initial execution of said commands >> less likely. > > I think that the function to prohibit DELETE and UPDATE without a > WHERE clause in the later response is good way.
This has popped up already in the lists in the past. > But I think that it is impossible to completely eliminate the failure > of the other commands. For example, drop the wrong table. This kind of thing is heavily application-dependent. For example, you would likely not care if an operator, who has newly-joined the team in charge of the maintenance of this data, drops unfortunately a table which includes logs from 10 years back, and you would very likely care about a table dropped which has user's login data. My point is that you need to carefully design the shape of the configuration you would use, so as any application's admin would be able to cope with it, for example allowing exclusion filters with regular expressions could be a good idea to dig into. And also you need to think about it so as it is backward compatible. -- Michael
signature.asc
Description: PGP signature