You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In database dependency theory, it is legal to have a unique constraint (a kind of functional dependency) on the empty set of columns.
This is equivalent to having a unique constraint on a column of type (). A table can store at most one value of type (), so a table with such a constraint can store at most one column.
This is actually a very useful feature: it lets you have "global state" tables with only one row. But this could be considered an antipattern. We should decide whether or not to support it.
If we do want to support it, this may require some extra work. Our unique constraints are implemented with indexes, and I'm not sure if we support indexing on no columns. But this would be a backwards-compatible change.
The text was updated successfully, but these errors were encountered:
In database dependency theory, it is legal to have a unique constraint (a kind of functional dependency) on the empty set of columns.
This is equivalent to having a unique constraint on a column of type
()
. A table can store at most one value of type()
, so a table with such a constraint can store at most one column.This is actually a very useful feature: it lets you have "global state" tables with only one row. But this could be considered an antipattern. We should decide whether or not to support it.
If we do want to support it, this may require some extra work. Our unique constraints are implemented with indexes, and I'm not sure if we support indexing on no columns. But this would be a backwards-compatible change.
The text was updated successfully, but these errors were encountered: