| 641 |
Password should not be open text |
Find base table columns that name refers to the possibility that these are used to register passwords. Find the columns that have a CHECK constraint that seems to determine the minimal permitted length of the values in the column. Passwords in a database table must be hashed and salted. Checking the strength of the password by using a check constraint is in this case impossible and the check constraints that try to do it should be removed from the database. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 642 |
Perhaps 0 instead of o |
Find the names of database objects where 0 sign is perhaps used instead of o. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 643 |
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 |
2025-11-07 10:11 |
MIT License |
View |
| 644 |
Perhaps a CHECK constraint about the combination of truth values is missing |
Find base tables that have at least two columns that have Boolean type and have at least one Boolean column that is not covered by a CHECK constraint involving more than one Boolean column. The Boolean columns possibly mean that we want to record data about states. Often the states depend on each other. For instance, if an order is archived it must be inactive. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 645 |
Perhaps a CHECK constraint about the order of events is missing |
Find base tables that have at least two columns that have DATE or TIMESTAMP (with or without time zone) type and do not have any associated CHECK constraint that involves two or more of these columns. The columns mean that we want to record data about events or processes, which often have a certain order. Hence, in case of each row of such a table the values in these columns must be in a certain order. For instance, the end of a meeting cannot be earlier than the beginning of the meeting. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 646 |
Perhaps an existing domain could be used to define the properties of a base table column? |
Find non-foreifgn key base table columns that have not been defined based on a domain but that have the same properties (data type, field size, default value, and pemisson to use NULLs) as some domain. If you define a domain, then you should try to use it in case of multiple columns. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 647 |
Perhaps an inconsistent use of NO ACTION and RESTRICT in the foreign key declarations |
Find as to whether in case of foreign key constraints both the compensating actions RESTRICT and NO ACTION are used within the same database. If the same thing has to do in different places, then try to do it in the same way. |
Problem detection |
system catalog base tables only |
2025-11-07 10:11 |
MIT License |
View |
| 648 |
Perhaps an overcomplicated constraint expression that compares the result of a Boolean expression with a Boolean value |
Find table and domain CHECK constraints that compare the result of a Boolean expression with a Boolean value. If you can choose between two logically equivalent Boolean expressions choose the more simple expression. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 649 |
Perhaps an unnecessary default value (the empty string or a string that consists of only whitespace) of a base table column/domain |
This query identifies table columns and domains that are configured with a semantically void DEFAULT value. It specifically flags defaults that are an empty string ('') or a string consisting solely of whitespace characters (e.g., spaces, newlines). This practice is a design flaw because it automatically populates the database with non-substantive data, which can lead to application-level bugs when code does not explicitly check for such "blank" values in addition to NULL. |
Problem detection |
INFORMATION_SCHEMA only |
2025-11-12 15:02 |
MIT License |
View |
| 650 |
Perhaps an unsuitable use of CHAR(n) type in base tables (based on check constraints) |
This query identifies a logical redundancy and likely data type misuse by finding CHAR columns that have a CHECK constraint on their value's length. The CHAR(n) data type is fixed-width and space-padded, meaning any non-NULL value will have a character length of exactly n. Therefore, a CHECK constraint on length is either superfluous (if it checks <= n) or will always fail (if it checks < n). This pattern indicates that the developer intended to store a variable-length string with a maximum length, for which the VARCHAR data type is the correct and more efficient choice. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-13 15:08 |
MIT License |
View |
| 651 |
Perhaps an unsuitable use of CHAR(n) type in base tables (based on names) |
This query identifies the semantic misuse of the CHAR(n) data type for non-foreign key columns where n > 1. It operates on a heuristic, flagging columns whose names suggest they store variable-length data (e.g., "name", "comment", "description", "email") rather than genuinely fixed-length data like standardized codes or hash values. Because CHAR(n) is a fixed-width, space-padded type, its use for variable-length strings is inefficient in terms of storage and can introduce application-level logic errors, making VARCHAR(n) the appropriate alternative. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-13 15:08 |
MIT License |
View |
| 652 |
Perhaps a redundant column (based on sequence generators) |
Find base tables where more than one column gets the default value by using the sequence generator mechanism. |
Problem detection |
INFORMATION_SCHEMA only |
2025-11-07 10:11 |
MIT License |
View |
| 653 |
Perhaps a reference to the variable NEW is missing |
Find row level before insert and before update triggers that only task is not to raise an exception and where the variable NEW is not used in the trigger routine outside the RETURN clause. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 654 |
Perhaps a reference to the variable OLD is missing |
Find row level before delete triggers that only task is not to raise an exception and where the variable OLD is not used in the trigger routine outside the RETURN clause. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 655 |
Perhaps a regular expression could be simplified |
Find regular expressions that name character classes a-zA-Z. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 656 |
Perhaps a relationship should be irreflexive |
Enforce all the constraints. A binary relation is called irreflexive, if it does not relate any element to itself. |
Problem detection |
system catalog base tables only |
2025-11-07 10:11 |
MIT License |
View |
| 657 |
Perhaps a state machine is implemented with Boolean columns |
Find implementations of state machines that uses a set of one or more Boolean columns. These columns could have the type Boolean or could probably (based on the column name and non-participation in a foreign key) contain values that represent truth values. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 658 |
Perhaps a state machine is implemented with timestamp columns |
Find implementations of state machines that uses a set of columns with a timestamp type. |
Problem detection |
INFORMATION_SCHEMA only |
2025-11-07 10:11 |
MIT License |
View |
| 659 |
Perhaps a too generic foreign key column name |
Find the names of foreign key columns that are too generic. The expressive names of table columns allow database users better and more quickly understand the meaning of data in the database. A person could participate in a process or be associated with an object due to different reasons. Thus, foreign key column names like isik_id, person_id, tootaja_id, worker_id etc. are too generic. The name should refer (also) to the reason why the person is connected. |
Problem detection |
system catalog base tables only |
2025-11-07 10:11 |
MIT License |
View |
| 660 |
Perhaps a too long name, which has been automatically shortened |
Find names (identifiers) of user-defined database objects that are 63 bytes long. This is the longest permitted length of identifiers if the default value of the NAMEDATALEN parameter has not been changed. PostgreSQL shortens too long identifiers automatically. Automatic code modification could break it somewhere. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |