Hello. One more weight comes here. At Sat, 15 Dec 2018 08:03:46 +0530, Amit Kapila <amit.kapil...@gmail.com> wrote in <CAA4eK1JHaibcX_Sf9eboDFV-OhHAw93XiD46rK=hnzsnhrd...@mail.gmail.com> > On Sat, Dec 15, 2018 at 12:14 AM Robert Haas <robertmh...@gmail.com> wrote: > > > > On Wed, Nov 28, 2018 at 1:43 PM Alvaro Herrera <alvhe...@2ndquadrant.com> > > wrote: > > > 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. > > > > I'm showing up very late to the party here, > > > > Not a problem, people like you are always welcome. > > > but I like option 1 best. > > > > You are not alone in this camp, so, IIUC, below are voting by different people > > Option-1: Vik, Sergei, Robert > Option-2: Alvaro, Magnus > Option-3: Michael, Hari > Option-4: Amit, Hari, Magnus, Alvaro, Michael, Peter > > Some people's name is present in two options as they are okay with > either one of those. I see that now more people are in favor of > option-1, but still, the tilt is more towards option-4. > > > I feel like the SQL standard has a pretty clear idea that NULL is how > > you represent a value is unknown, which shows up in a lot of places. > > Deciding that we're going to use a different sentinel value in this > > one case because NULL is a confusing concept in general seems pretty > > strange to me. > > > > I agree that NULL seems to be the attractive choice for a default > value, but we have to also see what it means? In this case, NULL will > mean 'all' which doesn't go with generally what NULL means (aka > unknown, only NULL can be compared with other NULL). There are a few > people on this thread who feel that having NULL can lead to misuse of > this API [1] as explained here and probably we need to use some > workaround for it to be used in production [2]. > [1] - > https://www.postgresql.org/message-id/CAA4eK1LicqWY55XxmahQXti4RjQ28iuASAk1X8%2ByKX0J051_VQ%40mail.gmail.com > [2] - > https://www.postgresql.org/message-id/20181117111653.cetidngkgol5e5xn%40alvherre.pgsql
Although #1 seems cleaner to me, the fear of inadvertent removal of all queries with quite-common usage wins. So I vote for #4 for now, supposing pg_stat_statements_reset(0, 0, 0) as all-clear. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
