Hello. One more weight comes here.
At Sat, 15 Dec 2018 08:03:46 +0530, Amit Kapila <amit.kapila16@gmail.com> wrote in
<CAA4eK1JHaibcX_Sf9eboDFV-OhHAw93XiD46rK=hnzSNHRD3oA@mail.gmail.com>
> On Sat, Dec 15, 2018 at 12:14 AM Robert Haas <robertmhaas@gmail.com> wrote:
> >
> > On Wed, Nov 28, 2018 at 1:43 PM Alvaro Herrera <alvherre@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
