Re: New function pg_stat_statements_reset_query() to reset statistics of a specific query

On Tue, Nov 20, 2018 at 10:56 AM Haribabu Kommi
<kommi(dot)haribabu(at)gmail(dot)com> wrote:
>
> On Tue, Nov 20, 2018 at 2:06 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>>
>> On Mon, Nov 19, 2018 at 10:48 AM Haribabu Kommi
>> <kommi(dot)haribabu(at)gmail(dot)com> wrote:
>> > On Mon, Nov 19, 2018 at 1:37 PM Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
>> >>
>> >> On 2018-Nov-19, Michael Paquier wrote:
>> >>
>> >> > On Mon, Nov 19, 2018 at 10:41:22AM +1100, Haribabu Kommi wrote:
>> >> > > 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
>> >> > > only some combinations.
>> >> >
>> >> > That's bloating the interface in my opinion.
>> >>
>> >> I understand.
>> >>
>> >> Let's call for a vote from a larger audience. It's important to get
>> >> this interface right, ISTM.
>> >
>> > 4. Single API with -1 as invalid value, treat NULL as no matching. (Only problem
>> > with this approach is till now -1 is also a valid queryid, but setting -1 as queryid
>> > needs to be avoided.
>> >
>>
>> Hmm, can we use 0 as default value without any such caveat?
>
>
> Yes, with strict and 0 as default value can work.
> If there is no problem, I can go ahead with the above changes?
>

I would say wait for a few days (at least 2 days) to see if Alvaro or
anybody else has an opinion on this.

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com