| # | Name ▲ | Goal | Type | Data source | Last update | License | |
|---|---|---|---|---|---|---|---|
| 741 | Recursive triggers that directly modify their home table | Do not cause potentially infinite loops. Recursive trigger fire themselves over and over again. If the system is not able to stop these, then it eventually consumes all the resources of the system. Although the system is able to detect these it is better to avoid creating these altogether. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 10:11 | MIT License | View |
| 742 | Redundant CHECK constraints (logical subsumption or equivalence) (empty strings and strings that consist of whitespace characters) | This query identifies redundant CHECK constraints by detecting cases of logical equivalence or subsumption on a single column. For instance, a constraint like description !~ '^[[:space:]]*$' logically subsumes a less comprehensive constraint such as description <> '', rendering the latter superfluous. Eliminating such duplication is a best practice that improves schema clarity, reduces maintenance overhead, and removes logical noise. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-19 14:54 | MIT License | View |
| 743 | Redundant CHECK constraints (logical subsumption or equivalence) (empty strings and strings that consist of whitespace characters) (2) | This query identifies superfluous CHECK constraints by detecting logical subsumption. It targets columns where a general non-blankness constraint is made redundant by a more specific, format-validating constraint. For instance, if an e_mail column is validated by a format constraint from Set1 (e.g., e_mail LIKE '%@%'), that constraint implicitly ensures the string is not blank. Therefore, any co-existing constraint from Set2 (e.g., e_mail !~ '^[[:space:]]*$') is logically unnecessary and can be removed to reduce schema complexity. Example. Set1: {e_mail~'[[:alnum:]@]+'; position('@' in e_mail)>0; e_mail LIKE '%@%'} Set2: {e_mail~'\S'; e_mail!~'^[[:space:]]*$'; e_mail!~'^\s*$'} If column e_mail has a constraint from Set1, then it does not need a constraint from Set2. |
Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-19 17:20 | MIT License | View |
| 744 | Redundant indexes | Find indexes that may be redundant. In addition to identical indexes it also considers indexes that cover the same columns and have the same properties except uniqueness. The query considers all types of indexes, including indexes that have been automatically created to support a constraint and function-based indexes. | Problem detection | system catalog base tables only | 2025-11-07 10:11 | MIT License | View |
| 745 | Redundant leading or trailing wildcards in regular expressions | This query identifies regular expressions that contain superfluous .* constructs at the beginning or end of the pattern. In standard unanchored regular expression matching (as performed by PostgreSQL's ~ operator), the engine checks for the pattern's existence anywhere within the string by default. Therefore, a leading or trailing .* is typically redundant, as it explicitly instructs the engine to do what it would already be doing implicitly. Removing these unnecessary wildcards improves the readability and maintainability of the expression and can, in some cases, lead to better performance by reducing unnecessary backtracking. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-15 10:04 | MIT License | View |
| 746 | Redundant trim() function in whitespace constraints | This query identifies superfluous trim() function calls within CHECK constraints where the validation is performed by a regular expression that disallows whitespace-only strings. A constraint using the pattern column !~ '^[[:space:]]*$' already provides comprehensive validation against empty or whitespace-only strings by anchoring the check to the start (^) and end ($) of the string. The trim() function is a pre-processing step that does not alter the boolean outcome of this specific regex match, making the expression trim(column) !~ '^[[:space:]]*$' functionally equivalent to the simpler column !~ '^[[:space:]]*$'. Removing the unnecessary function call improves clarity and simplifies the constraint. | Problem detection | INFORMATION_SCHEMA only | 2025-11-17 13:26 | MIT License | View |
| 747 | Reference to the numeric type is too imprecise, i.e., precision and scale are missing | Find base table columns that have the DECIMAL/NUMERIC type, but do not have precision and scale specified. "Specifying: NUMERIC without any precision or scale creates a column in which numeric values of any precision and scale can be stored, up to the implementation limit on precision. A column of this kind will not coerce input values to any particular scale, whereas numeric columns with a declared scale will coerce input values to that scale." | Problem detection | INFORMATION_SCHEMA only | 2025-11-07 10:11 | MIT License | View |
| 748 | Referential degree of a schema | Referential degree of a schema is defined as the number of foreign keys in the database schema. | Sofware measure | INFORMATION_SCHEMA only | 2025-11-07 10:11 | MIT License | View |
| 749 | Referential degree of tables | This metric represents the number of foreign keys in a base table. | Sofware measure | INFORMATION_SCHEMA only | 2025-11-07 10:11 | MIT License | View |
| 750 | Referential degree of tables (ver 2) | Find how many base tables are referenced from a base table by using foreign keys. | Sofware measure | system catalog base tables only | 2025-11-07 10:11 | MIT License | View |
| 751 | Registration/modification time is not automatically set | Find columns of base tables that name and type suggest that the column should contain the row registration time or last modify time but the column does not have a default value. | Problem detection | INFORMATION_SCHEMA only | 2025-11-07 10:11 | MIT License | View |
| 752 | Registration/modification time is not mandatory | Find columns that contain registration or modification time but are optional. | Problem detection | INFORMATION_SCHEMA only | 2025-11-07 10:11 | MIT License | View |
| 753 | Regular expression with possibly a LIKE pattern | Find expressions that use a regular expression with a like predicate pattern. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 10:11 | MIT License | View |
| 754 | Routine body has keywords that are not in uppercase | Keywords in uppercase improve readability. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 10:11 | MIT License | View |
| 755 | Routine body only in uppercase | Uppercase means screaming and having code entirely in uppercase makes its reading more difficult. On the other hand, it would be a good idea to have keywords in uppercase. Find routines that body contains a SQL data manipulation statement (which shouldn't be entirely in uppercase) but still the body is completely in uppercase. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 10:11 | MIT License | View |
| 756 | Routine body with ordering the query result based on positional references | Find routines where the query result is sorted based on the column number in the SELECT clause. Such query is sensitive towards changing the order of columns in the SELECT clause, i.e., if one changes the order of columns in the SELECT clause, then one must change the numbers in the ORDER BY clause as well, otherwise the query will produce undesired order of rows. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 10:11 | MIT License | View |
| 757 | Routine for reading data uses another routine to read some data | Find routines that only read data but invoke some other routine to read some more data. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 10:11 | MIT License | View |
| 758 | Routines that can be invoked with a variable number of arguments | Find routines with a VARIADIC parameter. These are routines that take as input an undefined number of arguments where the argument that is an undefined number are all of the same type and are the last input arguments. | General | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 10:11 | MIT License | View |
| 759 | Routines that use old syntax for limiting rows | This query identifies PL/pgSQL and SQL routines with no SQL-standard bodies that use the non-standard LIMIT clause for row limitation. It flags these routines because the official, cross-platform SQL standard specifies FETCH FIRST n ROWS ONLY for this purpose. Adhering to the standard improves code portability and maintainability. To ensure relevance, the query intelligently excludes routines that are part of installed extensions, focusing only on user-defined code. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-21 17:37 | MIT License | View |
| 760 | Routines with BOOLEAN return type that do not have a good name | This query audits the naming conventions of routines that return a BOOLEAN data type. It identifies routines that do not adhere to the recommended semantic prefix convention (i.e., starting with is_, has_, can_, or on_). A function name should represent a state or a question (e.g., has_rights) rather than an action (e.g., check_rights). Enforcing this standard makes the routine's purpose and return value immediately obvious from its name. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-13 13:53 | MIT License | View |