| # | Name ▲ | Goal | Type | Data source | Last update | License | |
|---|---|---|---|---|---|---|---|
| 441 | Incorrect check of NULLs | Find the use of =NULL and <>NULL in case of table level check constraints, domain level check constraints, WHEN clauses of triggers, WHERE clauses of rules, subqueries of derived tables, and bodies of routines. Write correct code. In order to determine as to whether a value is missing or not one has to use the IS [NOT] NULL predicate. NULL is the marker in SQL that denotes a missing value. Although it is often called "NULL value", one cannot treat it as an ordinary value, i.e., use it in comparisons as a value. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 10:11 | MIT License | View |
| 442 | Incorrect comparison operator | Find PL/pgSQL routines that use comparison operators =< or =>. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 10:11 | MIT License | View |
| 443 | Incorrect data type (based on default values) | Find columns of base tables that have the default value CURRENT_USER or SESSION_USER but the data type is CHAR or TEXT. | Problem detection | INFORMATION_SCHEMA only | 2025-11-07 10:11 | MIT License | View |
| 444 | Incorrect field size (based on default values) | This query identifies a potential schema mismatch regarding data precision. It flags base table columns that default to CURRENT_USER or SESSION_USER but define a character length differing from the PostgreSQL standard identifier limit (typically 63 bytes, defined by NAMEDATALEN - 1). Risk (Length < 63): Poses a hard runtime failure risk if a username exceeds the defined length. Inefficiency (Length > 63): Indicates imprecise modeling, as the stored value can technically never exceed the system limit. |
Problem detection | INFORMATION_SCHEMA only | 2025-12-15 11:09 | MIT License | View |
| 445 | Incorrect field size (based on default values) (2) | This query identifies potential schema discrepancies related to column sizing. It flags text columns in base tables where the static default value is unusually short—specifically, less than half the column's maximum allowed capacity. | Problem detection | INFORMATION_SCHEMA only | 2026-05-05 15:16 | MIT License | View |
| 446 | Incorrect password hash update | Find row level update triggers that incorrectly implement update of password hash. It should not be that the new password hash is calculated based on the existing hash. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 10:11 | MIT License | View |
| 447 | 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 |
| 448 | Incorrect prevention of the empty string or strings that consist of only spaces in a field | This query identifies ineffectual CHECK constraints on base and foreign table columns that incorrectly attempt to prohibit empty or whitespace-only strings using the predicate trim(column_name) IS NOT NULL. Due to PostgreSQL's strict distinction between an empty string ('') and NULL, this check is a tautology; trim('') evaluates to '', and the condition '' IS NOT NULL is always true. The query finds these logically flawed constraints, which fail to provide any data validation and permit the insertion of the exact values they were intended to prevent. | Problem detection | INFORMATION_SCHEMA only | 2025-11-12 14:56 | MIT License | View |
| 449 | Incorrect reference to a system-defined function in the routine body | Find user-defined routines that possibly use incorrect name of a system-defined function (currenttimestamp (correct is current_timestamp), currentdate (correct is current_date), currenttime (correct is current_time), local_time (correct is localtime), local_timestamp (correct is localtimestamp),localdate (there is no such function),local_date (there is no such function), sessionuser (correct is session_user), ucase (correct is upper), lcase (correct is lower)). The problem can arise only if the routine uses dynamic SQL. In case of static SQL the DBMS checks the SQL statemen at the creation time and finds out that for instance, SELECT Count(*) AS cnt FROM Emp WHERE hiredate<=currentdate; is incorrect statement because currentdate is not a function name and there is no column currentdate in the table Emp. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 10:11 | MIT License | View |
| 450 | Incorrect specification of logical or in regular expressions | Find the use of regular expressions where logical or is incorrectly specified, i.e., (| or |). | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 10:11 | MIT License | View |
| 451 | 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 |
| 452 | Incorrect use of COUNT(*) with outer joins | This query identifies user-defined routines and derived tables (views or materialized views) that use the COUNT(*) aggregate function (without a FILTER clause) alongside an OUTER JOIN and a GROUP BY clause. This combination is a common SQL anti-pattern. When grouping with an outer join, COUNT(*) counts the rows themselves, including the NULL-filled rows generated for non-matching records. Consequently, it inaccurately reports a count of 1 for completely empty groups instead of the correct count of 0. To get accurate results, developers should count a specific non-null column from the joined table. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2026-06-02 14:41 | MIT License | View |
| 453 | Incorrect use of non-deterministic functions in CHECK constraints | This query identifies CHECK constraints that use non-deterministic time functions (such as now or current_date) in a way that causes initially valid data to become invalid over time. For example, a constraint like localtimestamp(0) > end_date is an anti-pattern because advancing time will eventually violate it. However, safe implementations—such as birth_date < CURRENT_DATE—are permitted, because once the condition is met, it remains true indefinitely as time moves forward. | Problem detection | INFORMATION_SCHEMA only | 2026-06-01 15:37 | MIT License | View |
| 454 | Index FILLFACTOR is not default | This query generates a list of all indexes with an explicitly configured, non-default FILLFACTOR for the purpose of a performance audit. The query is aware of the different default FILLFACTOR values associated with various index access methods (e.g., 90 for B-tree, 100 for others like GiST/GIN). This allows administrators to quickly identify and review all instances of customized index storage parameters to assess if these non-standard configurations are justified and still effective. | General | system catalog base tables only | 2025-11-10 09:17 | MIT License | View |
| 455 | INFORMATION_SCHEMA is missing | Make sure that you do not drop INFORMATION_SCHEMA schema. In this case most of the design checking queries will not work. This schema automatically exists in all databases. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 10:11 | MIT License | View |
| 456 | Input parameters that names do not follow the convention to start with _ or p_ | For the sake of making code better understandable follow naming conventions. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 10:11 | MIT License | View |
| 457 | Input parameters with the same name have different types | This query analyzes the semantic consistency of routine signatures by identifying named input parameters that share an identical identifier but possess divergent data types across different routines. While this pattern is a prerequisite for valid routine overloading (polymorphism), it can also indicate a lack of standardization in the data dictionary. For example, using the parameter name status to denote an INTEGER in one context and TEXT in another creates ambiguity regarding the parameter's expected domain. The query results should be audited to distinguish intentional overloading from naming inconsistencies. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-12-15 11:34 | MIT License | View |
| 458 | Installed extensions | Try to use as much the possibilities of the DBMS as possible. On the other hand, do not install extensions that are not needed in order not to overcomplicate the database. | General | system catalog base tables only | 2025-11-07 10:11 | MIT License | View |
| 459 | Insufficient length for international personal codes | This query identifies varchar columns in base tables whose names suggest they store national identification numbers (personal codes), specifically in tables that also include a country code column. This combination implies that the table stores personal codes from various countries. To safely accommodate different international formats, the field size of the personal code column should be at least 20 characters. The query flags any such columns that are too short. | Problem detection | INFORMATION_SCHEMA only | 2026-06-01 16:02 | MIT License | View |
| 460 | Insufficient number of user-defined base tables | This query performs a basic structural assessment of the database schema by counting the number of user-defined base tables. It verifies whether the data model meets a minimum complexity threshold, requiring the existence of at least 7 distinct base tables. This metric serves as a proxy for the scope and depth of the implemented domain model. | Problem detection | INFORMATION_SCHEMA only | 2025-11-30 09:30 | MIT License | View |