On 2018-Nov-17, Amit Kapila wrote: > On Sat, Nov 17, 2018 at 4:46 PM Alvaro Herrera <alvhe...@2ndquadrant.com> > wrote:
> > Uh, ouch! Seems to me that this is a high-caliber foot-gun, and will > > cause nasty suprises when production stats data disappear inadvertently! > > What is the alternative in your mind? Well, as I see this interface, it is as if DELETE FROM ... WHERE queryid = <value> where passing a NULL value meant to delete *all* rows regardless of queryid, rather than only those where queryid is NULL. > AFAICS, we have below alternatives: > > a) Return an error for the NULL value of any argument? > b) Silently ignore if there is any NULL value argument and don't > remove any stats. > c) Just ignore the NULL value parameter and remove the stats based on > other parameters. > Currently, patch implements option (c), but we can do (a) or (b) as > well, however, that can make the API usage bit awkward. I think option d) is to have more functions (seven functions total), and have them all be strict (i.e. don't do anything if one argument is NULL). One function takes three arguments, and removes all entries matching the three. Other functions take two arguments, and remove everything matching those, ignoring the third (so behaving like the current NULL). Others take one argument. Maybe it doesn't make sense to provide all combinations, so it's less than seven. But having an interface that's inherently easy to misuse makes me a bit nervous. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
