6 ms·
>This change prohibits nothing, it allows specifying something (which was a bit complicated to enforce before). It allows specifying a constraint - that you ca
by faho 4y ago
>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.
- jamesmstone 4y agopre postgres 15 can you solve this with two unique constraints ? unique (EmployeeName), unique (EmployeeName, CarID)
- masklinn 4y agoYou’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 4y agoThat'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.
- masklinn 4y ago> 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.
- jhugo 4y agoKim being car-less would be represented by Kim not appearing in this table at all. The design you've presented makes no sense.
- deleted 4y ago[deleted]