| # | Name | Goal ▲ | Type | Data source | Last update | License | |
|---|---|---|---|---|---|---|---|
| 801 | Base tables and foreign tables that do not have any CHECK constraints on non-foreign key columns | Identify possibly missing CHECK constraints. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 10:11 | MIT License | View |
| 802 | The number of domains by schema and in total | Identify the number of domains in different schemas. | Sofware measure | INFORMATION_SCHEMA only | 2025-11-07 10:11 | MIT License | View |
| 803 | The number of sequence generators in different schemas | Identify the number of sequence generators in different schemas. Surrogate key values must be generated by using the system (the sequence generator mechanism in case of PostgreSQL). If there are no sequence generators, then there is a question as to whether there are no surrogate keys in the database at all (could be possible and OK) or (more probable) developers have forgotten to implement the generation of surrogate keys at the database level. An alternative is to implement generation of unique values at the application level or at the database level by using triggers. However, such implementation would most probably lead to the performance penalty because adding new rows to the table must be serialized, i.e., it can be done in one session at a time. | Sofware measure | INFORMATION_SCHEMA only | 2025-11-07 10:11 | MIT License | View |
| 804 | Triggers with SELECT (i.e., probably check data based on another table) | If a trigger is used for enforcing a constraint, then it should take into account that due to the implementation of multiversion concurrency control (MVCC) in PostgreSQL, reading data does not block data modification and vice versa. Thus, there may be a need to lock the entire table or some row explicitly. | General | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 10:11 | MIT License | View |
| 805 | Missing USAGE privileges on schema | If a user has a privilege to use a schema object, then the user must also have the usage privilege on the schema that contains the object. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 10:11 | MIT License | View |
| 806 | Potentially missing PRIMARY KEY or UNIQUE constraints (based on UUIDs) | If something has to be unique, then it must be said to the system so that it could use the information for internal optimizations and enforce the constraint. Find columns that contain Universally Unique Identifiers but are not a part of any simple PRIMARY KEY/UNIQUE constraint and are also not part of a foreign key. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 10:11 | MIT License | View |
| 807 | Incorrect prefix of a constraint name or an index name | If the name of an object has the prefix that refers to the type of the object (for instance, primary key constraint or foreign key constraint), then you should use references to the correct object type. Find prefixes of constraint names and index names that incorrectly refer to the type of the object. For instance, incorrect would be to use chk_ as the prefix of an index name or pk_ as the prefix of a check constraint name. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 10:11 | MIT License | View |
| 808 | Incorrect suffix of a constraint name or an index name | If the name of an object has the suffix that refers to the type of the object (for instance, primary key constraint or foreign key constraint), then you should use references to the correct object type. Find suffixes of constraint names and index names that incorrectly refer to the type of the object. For instance, incorrect would be to use _chk as the suffix of an index name or _pk as the suffix of a check constraint name. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 10:11 | MIT License | View |
| 809 | Parameter name is the same as the name of a used column | If the name of a routine parameter and the name of a column of a table that is used in the routine are the same, then it makes it more difficult to understand the code. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 10:11 | MIT License | View |
| 810 | Parameter name is the same as the name of a used column (ver 2) | If the name of a routine parameter and the name of a column of a table that is used in the routine are the same, then it makes it more difficult to understand the code. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 10:11 | MIT License | View |
| 811 | Privileges to use base table columns | If you do give privileges to base tables, then these should follow the principle of least privilege - the smallest possible amount of privileges to the smallest possible set of columns | General | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 10:11 | MIT License | View |
| 812 | No point to have in a procedure COMMIT without ROLLBACK or vice versa | If you end transaction in a procedure, then there should be a possibility to either commit or rollback the transaction based on some condition. Procedures appeared in PostgreSQL 11. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 10:11 | MIT License | View |
| 813 | CHECK constraints on columns with temporal data | If your table contains columns with temporal data, then it will be appropriate to restrict the range of possible values in these columns because some of the values that belong to the type might not be appropriate (for instance, imagine a client who was born in 1100-12-03 or a contract that was registered in 3890-12-12- 12:45). If your table contains multiple columns with temporal data that denote events, then the rule about the order of the events must be enforced, if possible. | General | INFORMATION_SCHEMA only | 2025-11-07 10:11 | MIT License | View |
| 814 | FOR UPDATE is not allowed with aggregate functions | Implement explicit locking correctly. Instead of writing, for instance, SELECT Count(*) AS cnt FROM person WHERE person_id=1 FOR UPDATE; one has to write SELECT person_id FROM person WHERE person_id=1 FOR UPDATE; | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 10:11 | MIT License | View |
| 815 | Names of database objects that contain two or more consecutive underscores or spaces as separators of name components | Improve the readability of names. Find the names (identifiers) of user-defined database objects that contain two or more consecutive underscores or spaces that separate name components, i.e., these are not at the beginning and in the end of the name. Example of such names are person__id or "person id". Names with duplicate underscores use snake case style but duplication of underscores does not improve the usability of the name. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 10:11 | MIT License | View |
| 816 | Names of database objects that start with an underscore | Improve the readability of names. Find the names (identifiers) of user-defined database objects that start with an underscore. This is not necessarily a mistake. For instance, parameter names could start with an underscore. On the other hand, it could be that the prefix is missing in the name. | General | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 10:11 | MIT License | View |
| 817 | The usage of double vs singular underscores or spaces in names as separator of name components | Improve the readability of names. Find the number of names (identifiers) of user-defined database objects that contain two or more consecutive underscores or spaces as the separator of name components vs. the number of names that contain a single underscore or space to separate name components. Try to be consistent in the usage of underscores. | Sofware measure | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 10:11 | MIT License | View |
| 818 | Inconsistent chain of relationships in terms of using ON UPDATE compensating action | In case of a chain of relationships between tables (where the primary key and the foreign key have the same columns) the use of ON UPDATE compensating action should be consistent. For instance, in the next example there is inconsistency, because if one changes the person_code in table Person, then the modification does not succeed because it does not cascade to the table Product. It is unclear as to whether it should be possible to change the person_code or not. Person (person_code, surname) Primary key (person_code) Worker(person_code) Primary key (person_code) Foreign key (person_code) References Person (person_code) ON UPDATE CASCADE Product(product_code, registrator) Primary key (product_code) Foreign key (registrator) References Worker (person_code) ON UPDATE NO ACTION |
Problem detection | system catalog base tables only | 2025-11-07 10:11 | MIT License | View |
| 819 | JSON type instead of JSONB type | "In general, most applications should prefer to store JSON data as jsonb, unless there are quite specialized needs, such as legacy assumptions about ordering of object keys." (https://www.postgresql.org/docs/current/datatype-json.html) | Problem detection | INFORMATION_SCHEMA only | 2025-11-07 10:11 | MIT License | View |
| 820 | Initially deferred constraint triggers with unnecessary locking | Initially deferred constraint triggers do not need explicit statements for locking tables or rows. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 10:11 | MIT License | View |