On Wed, Dec 12, 2018 at 3:54 PM Haribabu Kommi <kommi.harib...@gmail.com> wrote: > > > 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. >
Thanks for the updated patch. I will look into it in the next few days. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
