> > 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.
Following are the combinations that are possible and function name as
also pg_stat_statements_reset_by_***
userid,
dbid
queryid
userid, dbid
userid, queryid
dbid, queryid
userid, dbid, queryid -- Existing function name with arguments can work.
So 6 new functions needs to be added to cover all the above cases,
IMO, we may need functions for all combinations, because I feel some
user may have the requirement of left out combination, in case if we choose
