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
This is a critical issue for PrimaryKey and Unique constraints because these constraints create indexes, for which column order is very important. For example, a primary key PRIMARY KEY (a, b, c) creates a unique index that behaves like Haskell type Map A (Map B (Map C Value)). Due to the use of Set, the columns may be out of order. In my project, I saw primary keys in reverse order, equivalent to Haskell type Map C (Map B (Map A Value)). A query to select all values for a given A and B performs well with the correct primary key order, but it performs terribly with the incorrect primary key order.
The use of Set for ForeignKey constraints does not result in incorrect constraints because PostgreSQL supports foreign key constraints with columns in any order. It is best practice to put the columns in natural order, however, so use of Set results in inelegant constraints in the schema.
To fix this issue, I changed all of the TableConstraint constructors to use Vector instead of Set to store the column information. With ordered columns, primary key and unique constraints are correct, and foreign key constraints maintain elegant column order. This is a breaking change; it may change the order of columns in constraints that have more than one column. I will submit a pull request with the fix.
This changes constraints to store columns using `Vector` instead of
`Set`, so that the order is maintained. This is critically important
for primary key and unique constraints, and it improves the elegance of
foreign key constraints. This is a breaking change.
Currently,
TableConstrint
columns are stored usingSet
, so the order is determined bySet.toList
.This is a critical issue for
PrimaryKey
andUnique
constraints because these constraints create indexes, for which column order is very important. For example, a primary keyPRIMARY KEY (a, b, c)
creates a unique index that behaves like Haskell typeMap A (Map B (Map C Value))
. Due to the use ofSet
, the columns may be out of order. In my project, I saw primary keys in reverse order, equivalent to Haskell typeMap C (Map B (Map A Value))
. A query to select all values for a givenA
andB
performs well with the correct primary key order, but it performs terribly with the incorrect primary key order.The use of
Set
forForeignKey
constraints does not result in incorrect constraints becausePostgreSQL
supports foreign key constraints with columns in any order. It is best practice to put the columns in natural order, however, so use ofSet
results in inelegant constraints in the schema.To fix this issue, I changed all of the
TableConstraint
constructors to useVector
instead ofSet
to store the column information. With ordered columns, primary key and unique constraints are correct, and foreign key constraints maintain elegant column order. This is a breaking change; it may change the order of columns in constraints that have more than one column. I will submit a pull request with the fix.tc-develop
DocumentationThe text was updated successfully, but these errors were encountered: