| 841 | Columns of derived tables that name has been given by the system (2) | Find columns of derived tables (i.e., views and materialized views) where in the creation statement of the table the name of the column has not been specified, i.e., it is generated by the system. | Problem detection | system catalog base tables only | 2023-12-21 12:17 | MIT License | |
| 842 | Comments of columns | Find all comments of columns of tables. | General | system catalog base tables only | 2023-10-18 14:09 | MIT License | |
| 843 | Comments of derived tables | Find comments of derived tables (views and materialized views) that are registered in the system catalog witht a COMMENT statement. Find also comments on their associated objects (columns, triggers, rules). Make sure that the comments give relevant, useful, and correct information. | General | system catalog base tables only | 2023-01-19 12:14 | MIT License | |
| 844 | Comments of non-derived tables | Find comments of non-derived tables (base tables, foreign tables, and partitioned tables) that are registered in the system catalog witht a COMMENT statement. Find also comments on their associated objects (columns, constraints, indexes, triggers, rules). Make sure that the comments give relevant, useful, and correct information. | General | system catalog base tables only | 2023-01-19 12:30 | MIT License | |
| 845 | Comments of schemas, sequences, types, domains, domain constraints, and event triggers | Find all the comments that have been added with a COMMENT statement to schemas, sequences, types, domains, and event triggers. | General | system catalog base tables only | 2023-01-19 15:04 | MIT License | |
| 846 | 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 | |
| 847 | 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 | |
| 848 | 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 | |
| 849 | 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 | |
| 850 | 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 | |
| 851 | 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 | |
| 852 | 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 | |
| 853 | 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 | |
| 854 | 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 | |
| 855 | 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 | |
| 856 | Deferrable constraints | Find all deferrable constraints. | General | system catalog base tables only | 2021-10-08 11:25 | MIT License | |
| 857 | Deferrable foreign key constraint with a RESTRICT compensating action | Find deferrable foreign key constraint with ON UPDATE RESTRICT or ON DELETE RESTRICT compensating action. Referential actions are carried out before, and are not part of, the checking of a referential constraint. Deferring a referential constraint defers the checking of the of the constraint (a ) but does not defer the referential actions of the referential constraint. In PostgreSQL the essential difference between NO ACTION and RESTRICT is that NO ACTION allows the check to be deferred until later in the transaction, whereas RESTRICT does not. Thus RESTRICT could result with the failure of data modification where in case of NO ACTION the modification would succeed. | Problem detection | system catalog base tables only | 2021-10-08 11:29 | MIT License | |
| 858 | Definition of a non-minimal superkey instead of a candidate key (based on key constraints) | Find primary/key unique constraints (sets of columns) that are proper subsets of other primary key/unique constraints of the same table. 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, i.e., the keys should not have redundancy in terms of columns. | Problem detection | system catalog base tables only | 2021-10-16 10:29 | MIT License | |
| 859 | Definition of a non-minimal superkey instead of a candidate key (based on unique indexes) | Find pairs of non-partial unique indexes where the columns of a index are a proper subset of the columns of another index. Include indexes that support a constraint (primary key, unique, exclude), i.e., these indexes have been automatically created due to the constraint declaration. Exclude the pairs where both participants have been created to support a constraint. 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 keys based on candidate keys, i.e., the keys should not have redundancy in terms of columns. Defining a unique index essentially means defining a key in the table but it is done at the lower level of abstraction. | Problem detection | system catalog base tables only | 2022-10-21 15:56 | MIT License | |
| 860 | Depth of referential tree of a schema | Depth of referential tree of a database schema is the longest referential path between the tables in this schema (Piattini et al., 2001). In other words, it is the biggest value among the DRT(T) values of all the tables of the schema. | Sofware measure | system catalog base tables only | 2020-11-14 15:28 | MIT License | |