| 181 | Composite foreign keys | Find foreign keys that consist of more than one column. Make sure that the order of columns in the composite foreign key corresponds to the order of columns in the composite candidate key in the referenced table. | General | system catalog base tables only | 2020-11-06 14:51 | MIT License | |
| 182 | Composite foreign keys with a mix of mandatory and optional columns | Find composite foreign keys with a mix of mandatory and optional columns. In case of a composite foreign keys all the columns should either optional or mandatory in order to avoid problems with NULLs. | Problem detection | system catalog base tables only | 2021-02-25 17:29 | MIT License | |
| 183 | Composite foreign keys with an incorrect order of columns (ver 1) | Find composite foreign keys where the order of columns does not correspond to the order of columns in the referenced candidate key. Find composite foreign keys in case of which the foreign key and candidate key consist of columns with the same name but the order of columns in the keys is different. For instance, the query returns information about a foreign key (personal_code, country_code) that refers to the candidate key (country_code, personal_code). In SQL keys are ordered sets of columns. Thus, in case of composite foreign key declarations one has to pay attention that the order of columns in the FOREIGN KEY clause matches the order of columns in the REFERENCES clause. | Problem detection | system catalog base tables only | 2021-02-25 17:29 | MIT License | |
| 184 | Composite foreign keys with an incorrect order of columns (ver 2) | Find composite foreign keys where the order of columns does not correspond to the order of columns in the referenced candidate key. Find composite foreign keys in case of which the foreign key and candidate key are not the same in terms of data types of the columns. For instance, the query returns information about a foreign key that columns have the types (SMALLINT, INTEGER) that refers to the candidate key that columns have the types (INTEGER, SMALLINT). In SQL keys are ordered sets of columns. Thus, in case of composite foreign key declarations one has to pay attention that the order of columns in the FOREIGN KEY clause matches the order of columns in the REFERENCES clause. | Problem detection | system catalog base tables only | 2021-02-25 17:29 | MIT License | |
| 185 | Consistency of CHECK constraint name and content | Find all CHECK constraints that name contains a digit. Make sure that the name and the Boolean expression are consistent. | General | INFORMATION_SCHEMA only | 2021-12-10 13:21 | MIT License | |
| 186 | Consistency of comments of routines | Find user-defined routines that have a comment registered by the COMMENT statement and a comment within the routine body. Make sure that there are no inconsistencies between the comments. | General | INFORMATION_SCHEMA+system catalog base tables | 2021-11-04 10:56 | MIT License | |
| 187 | Consistency of using generic column names in candidate key columns that are not foreign key columns | Find the names on base table columns that are a part of a candidate key but not a foreign key and contain a generic word (nimi, nimetus, kommentaar, kirjeldus, name, comment, description, etc.). Make sure that naming of these is consistent, i.e., such names always contain the table name or never contain the table name. | General | INFORMATION_SCHEMA+system catalog base tables | 2023-01-14 20:53 | MIT License | |
| 188 | Consistency of using generic column names in non-candidate key columns that are also not foreign key columns | Find the names on base table columns that are not a part of a candidate key and a foreign key and contain a generic word (nimi, nimetus, kommentaar, kirjeldus, name, comment, description, etc.). Make sure that naming of these is consistent, i.e., such names always contain the table name or never contain the table name. | General | INFORMATION_SCHEMA+system catalog base tables | 2023-01-14 20:53 | MIT License | |
| 189 | Consistency of using NOT NULL constraints on Boolean base table columns | Find the number of mandatory and optional Boolean base table columns and the proportion of optional columns from all the Boolean columns. Use two-valued logic (TRUE, FALSE) instead of three-valued logic (TRUE, FALSE, UNKNOWN). Because NULL in a Boolean column means unknown make all the Boolean columns mandatory. | Sofware measure | INFORMATION_SCHEMA only | 2020-12-28 01:43 | MIT License | |
| 190 | Constraints that are not redefined in a subtable | Find primary key, unique, foreign key, and exclude constraints that have been defined in a supertable (parent table) but not in its subtable. Unfortunately, PostgreSQL table inheritance is implemented in a manner that some constraints (CHECK, NOT NULL) are inherited from the supertable but others are not. "All check constraints and not-null constraints on a parent table are automatically inherited by its children, unless explicitly specified otherwise with NO INHERIT clauses. Other types of constraints (unique, primary key, and foreign key constraints) are not inherited." (PostgreSQL documentation) | Problem detection | system catalog base tables only | 2021-02-25 17:29 | MIT License | |
| 191 | Constraints that are not redefined in a subtable and there is no CHECK constraint that compensates this | Find primary key, unique, foreign key, and exclude constraints that have been defined in a supertable (parent table) but not in its subtable. Additional condition is that in case of the subtable there is no CHECK that permits only one specific value in the constraint column. The presence of such check would make the design acceptable. Unfortunately, PostgreSQL table inheritance is implemented in a manner that some constraints (CHECK, NOT NULL) are inherited from the supertable but others are not. "All check constraints and not-null constraints on a parent table are automatically inherited by its children, unless explicitly specified otherwise with NO INHERIT clauses. Other types of constraints (unique, primary key, and foreign key constraints) are not inherited." (PostgreSQL documentation) | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2021-02-25 17:30 | MIT License | |
| 192 | Constraints that are not redefined in a subtable but there is a CHECK constraint that compensates this | Find primary key, unique, foreign key, and exclude constraints that have been defined in a supertable (parent table) but not in its subtable. Exclude constraints where in case of the subtable there is a CHECK that permits only one specific value in the constraint column. The presence of such check would make the design acceptable. Unfortunately, PostgreSQL table inheritance is implemented in a manner that some constraints (CHECK, NOT NULL) are inherited from the supertable but others are not. "All check constraints and not-null constraints on a parent table are automatically inherited by its children, unless explicitly specified otherwise with NO INHERIT clauses. Other types of constraints (unique, primary key, and foreign key constraints) are not inherited." (PostgreSQL documentation) | General | INFORMATION_SCHEMA+system catalog base tables | 2020-12-25 16:20 | MIT License | |
| 193 | Constraints that are redefined in a subtable. | Find primary key, unique, foreign key, and exclude constraints that have been defined in a supertable (parent table) and have been redefined in its subtable. | General | system catalog base tables only | 2020-12-02 17:28 | MIT License | |
| 194 | Constraint-supporting UNIQUE indexes with the same leading column | Find indexes that support a uniqueness constraint and have the same leading column. | General | system catalog base tables only | 2023-11-26 16:01 | MIT License | |
| 195 | Constraints with the same name within the same schema and constraint type | Find names of foreign key constraints that are used within the same schema more than once. Find names of check constraints that are used within the same schema more than once. Find names of constraint triggers that are used within the same schema more than once. Different things should have different names. But here different constraints have the same name. Also make sure that this is not a sign of duplication. | Problem detection | system catalog base tables only | 2022-11-15 16:43 | MIT License | |
| 196 | Coverage by derived tables | Find for each base table the list of derived tables (both views and materialized views) that refer to the base table. If the database is used through the public database interface (virtual data layer), then, ideally, each table is referred from the subquery of at least one derived table. | General | INFORMATION_SCHEMA+system catalog base tables | 2023-11-11 09:31 | MIT License | |
| 197 | Coverage by routines that have the SQL-standard body | Find for each base table the list of routines (functions and procedures) that refer to the base table. If the database is used through the public database interface (virtual data layer), then, ideally, each table is referred from at least one routine. | General | INFORMATION_SCHEMA+system catalog base tables | 2021-11-05 17:00 | MIT License | |
| 198 | Cycle in a hierarchy | There should not be cycles in hierarchies meaning that the parent must always be specified. In this case a parent must reference to a child or to itself, otherwise it cannot be registered. | Problem detection | system catalog base tables only | 2021-02-25 17:30 | MIT License | |
| 199 | Cycles in relationships | Find as to whether foreign key constraints between tables form a cycle. For instance, if table C refers to table B, table B refers to table A, table A refers to table C and all the foreign key columns are mandatory, then one cannot add data to the tables. Is cycle value in the result should not contain value TRUE. One should check manually as to whether the foreign key columns are mandatory or optional. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2021-11-28 15:15 | MIT License | |
| 200 | Database can be accessed through PUBLIC privileges | Find as to whether the database access by users (applications) can take place thanks to PUBLIC privileges, i.e., find as to whether PUBLIC (all current and future users) has CONNECT privilege in the database. PUBLIC gets the privilege by default. | Problem detection | system catalog base tables only | 2022-10-31 10:19 | MIT License | |