On Wed, Dec 12, 2018 at 3:54 PM Haribabu Kommi <kommi.haribabu@gmail.com> wrote:
>
>
> On Thu, Nov 29, 2018 at 1:57 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>>
>> On Wed, Nov 28, 2018 at 7:13 PM Alvaro Herrera <alvherre@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
