| 761 | Columns with exact/floating numeric types have textual default values | The default value of a column should belong to the type of the column. The system shouldn't conduct unnecessary type casts. | Problem detection | INFORMATION_SCHEMA only | 2021-02-25 17:29 | MIT License | |
| 762 | Columns with only one value | Find base table columns that contain only one value. Perhaps it is an unnecessary column. Having only one value is most likely inadequate for testing. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2021-02-25 17:29 | MIT License | |
| 763 | 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 | |
| 764 | 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 | |
| 765 | 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 | |
| 766 | 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 | |
| 767 | Definition of a non-minimal superkey instead of a candidate key (based on enumeration types) | Candidate key is a minimal superkey, meaning that it is not possible to remove columns from the candidate key without losing its uniqueness property. One should define primary key's and unique constraints based on candidate keys. Find primary key and unique constraints where a proper subset of columns has an enumeration type that permits only one value in the column. The candidate key should involve only columns without such type. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2021-02-25 17:29 | MIT License | |
| 768 | Derived table names have prefix or suffix | Find the names of views and materialized views that have prefix or suffix. Follow the same naming style as in case of base tables (derived tables are also tables). Thus, if base tables do not have prefixes or suffixes, then derived tables shouldn't have these as well. | Problem detection | system catalog base tables only | 2021-02-25 17:29 | MIT License | |
| 769 | Derived table on top of another derived table | Do not build multiple levels of derived tables (views and materialized views) because it will hamper evolvability and understandability of the tables. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2021-02-25 17:29 | MIT License | |
| 770 | Different prefixes of a candidate key column and a referencing foreign key column | The naming must be consistent. Find foreign key constraints where the candidate key column and foreign key column names have different prefixes. Thus, for instance, one cannot use USING syntax for joining the tables. | Problem detection | system catalog base tables only | 2021-02-25 17:29 | MIT License | |
| 771 | Different suffixes of a candidate key column and a referencing foreign key column | The naming must be consistent. Find foreign key constraints where the candidate key column and foreign key column names have different suffixes. Thus, for instance, one cannot use USING syntax for joining the tables. | Problem detection | system catalog base tables only | 2021-02-25 17:29 | MIT License | |
| 772 | Domain based on another domain | Find domains that have been defined based on another domain. Do not specify domains based on existing domains. This would unnecessarily increase dependencies and complexity. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2021-02-25 17:29 | MIT License | |
| 773 | Domain CHECK constraint name contains table name | Find names of domain CHECK constraints that contain the name of the base that column the domain specifies. Domains are reusable artifacts that one should be able to use in case of defining different base tables. Thus, it is inappropriate to use the name of a particular table in the name of a domain constraint. | Problem detection | INFORMATION_SCHEMA only | 2021-02-25 17:29 | MIT License | |
| 774 | Domain declares the same default value for multiple independent foreign keys | Find domains that declare a default value and that are used in case of multiple foreign key constraints that point to different tables. Domains should be used in a manner that does not cause unnecessary coupling of concerns. For instance, let us assume that columns client_state_type_code of table Client (that is used to implement the relationship with table Client_state_type) and worker_state_type_code of table Worker (that is used to implement the relationship with table Worker_state_type) have been defined based on the same domain. It the domain has a default value, then it determines the initial state of both clients and workers. However, it must be possible to determine the initial state independently in case of clients and workers. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2021-02-25 17:29 | MIT License | |
| 775 | Domain name contains base table name | Find names of domains that contain the name of the table that column the domain specifies. Domains are reusable artifacts that one should be able to use in case of different base tables. Thus, it is inappropriate to use the name of a particular table in the name of the domain. | Problem detection | INFORMATION_SCHEMA only | 2021-02-25 17:29 | MIT License | |
| 776 | Do not leave out the referential constraints (pairs of tables) | Try to find missing foreign key constraints. Find pairs of base table columns that have the similar name, perhaps the same type, and that are not associated through a foreign key relationship. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2021-02-25 17:29 | MIT License | |
| 777 | Do not use the money data type | Find base table columns with the Money data type. Each value of the money type has associated currency sign that depends on server settings. It could be $. Moreover, using the values for arithmetic operations requires casts that makes the code more complicated. | Problem detection | INFORMATION_SCHEMA only | 2021-02-25 17:29 | MIT License | |
| 778 | Double negatives in Boolean expressions | Write code that is simple to understand and not confusing. A double negative is a grammatical construction occurring when two forms of negation are used in the same expression (https://en.wikipedia.org/wiki/Double_negative). Double negatives in Boolean expressions make it more difficult to understand and maintain the code. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2021-02-25 17:29 | MIT License | |
| 779 | Do you really need fractional seconds? | Find default values that return current timestamp with the maximum number of fractional seconds (6). | Problem detection | INFORMATION_SCHEMA only | 2021-02-25 17:29 | MIT License | |
| 780 | Duplicate independent (i.e., not created based on a table) composite types | Find composite types with the same attributes (regardless of the order of attributes). Make sure that there is no duplication. | Problem detection | system catalog base tables only | 2021-02-25 17:29 | MIT License | |