On Thu, Nov 29, 2018 at 1:57 PM Amit Kapila <amit.kapil...@gmail.com> wrote:
> On Wed, Nov 28, 2018 at 7:13 PM Alvaro Herrera <alvhe...@2ndquadrant.com> > wrote: > > > > On 2018-Nov-28, Amit Kapila wrote: > > > > > The problem with this idea is that if someone specifies a particular > > > parameter using query and the query doesn't return any parameters, > > > then it can lead to inadvertent behavior. For example, if user uses > > > something like pg_stat_statements_reset(<valid_user_id>, > > > <valid_db_id>, SELECT s.queryid FROM pg_stat_statements AS s WHERE > > > s.query = 'SELECT $1 AS "ONE"'); now, if the query doesn't return any > > > row, we will remove the stats for all queries that belong to > > > (userid,dbid). It could be surprising for some users, that's why we > > > came up with option-4 where we keep the default value of parameters as > > > 0. > > > > Right, I think option 4 is a clear improvement over option 1. I can get > > behind that one. Since not many people care to vote, I think this tips > > the scales enough to that side. > > > > Agreed. Hari, can you change the patch as per the requirements of > option-4. > Apologies for delay. Thanks to all your opinions. Attached is the updated patch as per the option-4 and added a test also to ensure the function strictness. Regards, Haribabu Kommi Fujitsu Australia
0001-Extend-pg_stat_statements_reset-to-reset-statistics_v14.patch
Description: Binary data
