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
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com