| 101 | Mixing the use of TEXT and VARCHAR type in case of base table columns | Declaring a column to have the type TEXT or the type VARCHAR (without the maximum number of characters) has the same end result in terms of what data can be recorded in the column. Nevertheless, one should try to stick with using one of the type names in order to cause less confusion. "If you do something a certain way, do all similar things in the same way." (Robert C. Martin, Clean Code) | Problem detection | INFORMATION_SCHEMA only | 2024-12-14 13:41 | MIT License | |
| 102 | Number of views with and without security barrier | Find the number of views, the number of views with and without security barrier setting, and the names of views with and without the security barrier setting. | Sofware measure | INFORMATION_SCHEMA+system catalog base tables | 2024-12-13 19:41 | MIT License | |
| 103 | Views without security barrier | Find views that do not have the security barrier option. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2024-12-13 19:30 | MIT License | |
| 104 | Views with WHERE but without security barrier | Find views that do not have the security barrier option but restrict rows in some way. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2024-12-13 19:29 | MIT License | |
| 105 | Explicit locking is missing | PostgreSQL uses multiversion concurrency control (MVCC). SELECTs do not block modifications and vice versa. One has to take steps to achieve correct behaviour. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2024-12-13 14:57 | MIT License | |
| 106 | SELECT * in a routine body | SELECT statement should list the columns not use SELECT * to return data from all the columns. Firstly, it ensures, that the query asks only data that is really needed by the routine. It means less data that the DBMS has to fetch and pass to the routine. It could also mean that the DBMS can answer to a query based on an index without reading table blocks. Secondly, it documents the data that is returned by the query. The query does not consider objects that are a part of an extension. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2024-12-13 14:34 | MIT License | |
| 107 | NOT NULL constraint via CHECK instead of NOT NULL constraint | Find columns where the NOT NULL constraint has been added with the help of an explicit CHECK constraints instead of a NOT NULL constraint. One should note that internally NOT NULL constraints are treated as a kind of CHECK constraints. Nevertheless, the design should be consistent (i.e., NOT NULL is enforced with the same way in different places). | Problem detection | INFORMATION_SCHEMA only | 2024-12-12 09:42 | MIT License | |
| 108 | Perhaps inconsistent use of temporal functions (2) | Find as to whether in the same database more than one of these functions is used at the same time - now(), localtimestamp, current_timestamp. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2024-12-12 00:20 | MIT License | |
| 109 | Perhaps too many subconditions in a CHECK constraint | Find check constraints of base table and foreign table columns that are either associated with more than one column and have at least one AND operation or are associated with exactly one column and have two or more AND operations. | Problem detection | INFORMATION_SCHEMA only | 2024-12-11 23:29 | MIT License | |
| 110 | FILLFACTOR is probably too small (2) | Find base tables that probably implement many to many relationship type, have no clear sign that there are columns that should be updated, but still have fillfactor less than 100. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2024-12-11 14:38 | MIT License | |
| 111 | B-tree index fillfactor has been explicitly set to 90 | Find B-tree indexes that fillfactor has been explicitly set to 90. In case of B-tree indexes the default is 90. | Problem detection | system catalog base tables only | 2024-12-11 14:37 | MIT License | |
| 112 | Something is still to do in routines | Find routines where comments contain TODO phrase. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2024-12-11 12:44 | MIT License | |
| 113 | Row level triggers that update or delete data | Find row level triggers that update or delete data. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2024-12-11 12:27 | MIT License | |
| 114 | Perhaps a CHECK constraint about required personal name components is missing | Find base tables that have optional columns for recording both given name and surname and do not have a CHECK constraint that requires that at least one of the name components must be registered in case of each person. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2024-12-11 12:23 | MIT License | |
| 115 | Very similar (but not equal) routine names | Find pairs of names of different types of routines that are very similar but not equal. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2024-11-30 12:09 | MIT License | |
| 116 | Very similar domain names | Find pairs of names of domains that are very similar or even equal. | Problem detection | INFORMATION_SCHEMA only | 2024-11-30 12:07 | MIT License | |
| 117 | Very similar table names | Find pairs of names of different types of tables that are very similar or even equal. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2024-11-30 11:50 | MIT License | |
| 118 | Multicolumn CHECK constraints with with inconsistent Boolean expressions | Find CHECK constraints that involve two columns, i.e., the cardinality of the constraint is 2, the columns have the same name in different tables, and the Boolean expressions of these constraints are different. For instance, in one table it is last_change_time>=reg_time and in another table it is not (reg_time>last_change_time). | Problem detection | system catalog base tables only | 2024-11-30 10:46 | MIT License | |
| 119 | SQL functions that use optimistic approach for locking but do not return a value | Find SQL functions that use a hidden column of PostgreSQL tables - xmin - to implement optimistic locking but do not return any information to the invoker of the functions, i.e., whether the update/delete operation succeeded or not. The functions should let their invokers know as to whether the function succeeded in updating or deleting a row. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2024-11-30 10:02 | MIT License | |
| 120 | CHECK constraints are inconsistent with DEFAULT values | Find table CHECK constraints that involve two columns that have the same default value. However the constraint assumes that the values must be unequal or one value must be bigger than another. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2024-11-30 09:58 | MIT License | |