[faho]

>This change prohibits nothing, it allows specifying something (which was a bit complicated to enforce before).

It allows specifying a constraint - that you can't have two rows with the same values even if one of the values is a NULL. That's prohibiting duplicate NULLs. The change allows you to prohibit duplicate NULLs.

Say you have a table (EmployeeName, CarID). You could do a UNIQUE constraint on those two attributes, but that would still allow:

EmployeeName | CarID

Jeff | 2

Kim | NULL

Kim | NULL

Here, "Kim" is car-less (NULL in the CarID field) twice, which makes no sense.

Hence the new constraint.

[jhugo]

Kim being car-less would be represented by Kim not appearing in this table at all. The design you've presented makes no sense.

[masklinn]

> It allows specifying a constraint - that you can't have two rows with the same values even if one of the values is a NULL. That's prohibiting duplicate NULLs. The change allows you to prohibit duplicate NULLs.

Sure.

> Here, "Kim" is car-less (NULL in the CarID field) twice, which makes no sense.

The relation makes no sense to start with, it didn’t need duplicate nulls for that.

[jamesmstone]

pre postgres 15 can you solve this with two unique constraints ?

unique (EmployeeName), unique (EmployeeName, CarID)

[masklinn]

You’d most likely solve this by making the CarID NOT NULL because there’s why would you even have a row with no useful data?

And if this is your employee table, you’d have UNIQUE (EmployeeData) and UNIQUE (CarID), and it would do what you want.

[ryanbrunner]

That's not quite the same, since the previous solution of unique (EmployeeName, CarID) allowed for one employee to have 2 separate cars. You have to use conditional indexes to solve this.