On Sat, Nov 17, 2018 at 4:46 PM Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > > On 2018-Nov-17, Haribabu Kommi wrote: > > > > Okay, but you haven't answered my question: > > > "how is able to remove the correct statement from hash (it seems > > > statement intended to remove 'SELECT $1 AS "ONE"', but it removed > > > 'SELECT $1 + $2 AS "TWO"')"? > > > > I missed to check that question. > > > > SELECT s.queryid FROM pg_stat_statements AS s WHERE s.query = > > 'SELECT $1 AS "ONE"' > > > > With the above query to get the queryid, but there are no such queries > > present in the pg_stat_statements, so the above query returns NULL as > > output, and with NULL as input to the _reset() function, it takes the > > default value of 0, and the reset query compares with rest of the two > > parameters of userid and dbid. > > 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? 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 mean the user has to pass the valid value for all parameters or alternatively we need to keep some other default value of parameters which say that ignore this particular parameter and remove stats based on other parameters. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
