| 301 | 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 | |
| 302 | 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 | |
| 303 | 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 | |
| 304 | 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 | |
| 305 | 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 | |
| 306 | 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 | |
| 307 | Database connect privilege is missing | Find non-superusers who have a privilege to use a table or a routine but do not have the privilege to connect to the database. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2021-11-21 13:51 | MIT License | |
| 308 | Database objects of the same type and case insensitive name in the same container | Find database objects with the same type and case insensitive name in the same container. It can only happen if some of the names are case insensitive and others are case sensitive. For instance, the same schema can contain the table "Client" and client | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2024-12-21 17:13 | MIT License | |
| 309 | Database object that belong to the public interface (virtual data layer) and that names contain the letters õäöüÕÄÖÜ | Find database object that belong to the database public interface (virtual data layer - consists of routines and derived tables) and that names contain the letters õäöüÕÄÖÜ (Estonian letters with a diacritic). These letters belong to the Estonian alphabet but do not belong to the ASCII character set. Although permitted by the DBMS, such letters might make it more difficult to use the interface by other programs. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2021-02-25 17:30 | MIT License | |
| 310 | Database object that do not belong to the public interface (virtual data layer) and that names contain the letters õäöüÕÄÖÜ | Find database object that do not belong to the database public interface (virtual data layer - consists of routines and derived tables) and that names contain the letters õäöüÕÄÖÜ (Estonian letters with a diacritic). These letters belong to the Estonian alphabet but do not belong to the ASCII character set. Although permitted by the DBMS, such letters might make the naming style inconsistent with the naming style of elements that belong to the public interface. If applications access base tables directly, then the letters can cause the same problems as in case of derived tables, i.e., applications may have difficulties with such names. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2021-02-25 17:30 | MIT License | |
| 311 | Declaratively partitioned tables with one partition | Find declaratively partitioned tables that have exactly one partition. Declarative partitioning is implemented in PostgreSQL starting from PostgreSQL 10. If there is only one partition, then it raises question as to why the additional complexity associated with partitioning is needed. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2020-11-06 14:51 | MIT License | |
| 312 | Declaratively partitioned tables without partitions | Find declaratively partitioned tables that do not have any partitions. Declarative partitioning is implemented in PostgreSQL starting from PostgreSQL 10. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2021-02-25 17:30 | MIT License | |
| 313 | Default should be declared at the level of domain not at the level of base table columns | Find domains that have been used to define one or more base table non-foreign key columns and all the columns have the same default value that is associated directly with the column not with the domain. Write as little code as possible. If possible, move things "before the brackets" so to say. In this case it means declaring the default value at the level of the domain and not at the level of base table columns. An exception is when the domain is used to define foreign key columns. In this case, it would be appropriate to define the default value at the column level (because different foreign keys could have different default values). | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2021-02-25 17:30 | MIT License | |
| 314 | Definition of a non-minimal superkey instead of a candidate key (based on check constraints) | 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 a check constraint that permits only one value in the column. The candidate key should involve only columns without such constraint. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2024-04-30 20:25 | MIT License | |
| 315 | 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 | |
| 316 | Definition of a non-minimal superkey instead of a candidate key (based on sequence generators) | 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 keys and unique constraints where a proper subset of the key is a column with an associated sequence generator. Most certainly such subset contains unique values. Thus, this subset should be the key, not its superset. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2021-03-07 20:56 | MIT License | |
| 317 | Delimited identifiers | Delimited identifiers (quoted identifiers) are case sensitive. Identifiers of database objects should be case insensitive in order to simplify their management. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2024-12-21 17:21 | MIT License | |
| 318 | 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 | |
| 319 | Derived table presents the same data in the same way as a single base table | Find derived tables (views and materialized views) that present data from one base table without adding columns, renaming columns, changing the order of columns, removing columns, or restricting rows. Perhaps something is missing from the subquery of the derived table. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2023-12-25 12:15 | MIT License | |
| 320 | Derived tables that have a column with the xid type | Find the derived tables (views and materialized views) that have a column with the xid type, i.e., these use the data from the hidden xmin column of a base table. If one uses optimistic approach for dealing with the concurrent data modifications, then xmin values should be presented by views and used in routines that modify or delete rows. | General | INFORMATION_SCHEMA+system catalog base tables | 2020-11-06 14:51 | MIT License | |