| 801 |
Disabled system triggers (i.e., disabled enforcement of constraints) |
These triggers should be enabled because otherwise some important functionality regarding constraints like enforcing referential integrity does not work. |
Problem detection |
system catalog base tables only |
2025-11-07 10:11 |
MIT License |
View |
| 802 |
Logical size of a table |
The table size is the sum of the total size of the simple columns and the total size of the complex columns in the table. In case of SQL databases large base tables in terms of number of columns could be a side effect of the problems with cloned columns or multiple columns for the same attribute. A base table with a low normalization level, which is meant to hold data that corresponds to multiple entity types has typically also relatively large number of columns compared with other base tables. Thus, the normalization level of base tables with a large number of columns should be checked as well. |
Sofware measure |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 803 |
Pointlessly returned value |
The value that is returned by a function should depend on something. If you do not have anything meaningful to return (for instance, the function always returns true, false, NULL, or the same number), then write VOID instead of the return type. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:11 |
MIT License |
View |
| 804 |
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 |
| 805 |
Routine for reading data uses another routine to read some data |
This query analyzes the call graph of user-defined routines to identify nested data retrieval patterns. It flags routines that are operationally read-only (performing no DML) but rely on invoking other routines to access additional data. This indicates a layered architecture where data access logic is encapsulated and chained. Identifying these routines is essential for performance profiling, as the total cost of execution is distributed across the call stack rather than being contained within a single procedure body. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-12-26 11:48 |
MIT License |
View |
| 806 |
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 |
| 807 |
Insufficient number of user-defined non-trigger SQL routines with SQL-standard routine body |
This query assesses the database's adherence to modern SQL standards regarding procedural code. It verifies whether the schema contains a minimum of 3 user-defined, non-trigger routines that are specifically written in the SQL language and utilize a SQL-standard body (defined using BEGIN ATOMIC ... END). This excludes routines written in PL/pgSQL or those using the legacy string-literal body definition. The metric ensures a baseline adoption of the standardized, portable syntax for SQL routines introduced in newer PostgreSQL versions. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-30 09:22 |
MIT License |
View |
| 808 |
Insufficient number of user-defined triggers+rules |
This query assesses the extent of active logic implementation within the database schema. It verifies that there are at least 3 user-defined triggers or rewrite rules present in the database. These objects represent automated tasks that for example enforce complex integrity constraints. Meeting this threshold indicates a baseline competency in utilizing PostgreSQL's event-driven capabilities. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-30 09:36 |
MIT License |
View |
| 809 |
Insufficient number of user-defined triggers+rules (based on number of tasks) |
This query assesses the extent of active logic implementation within the database schema. It verifies that there are user-defined triggers or rewrite rules present for at least 3 tasks. These objects represent automated tasks that for example enforce complex integrity constraints. Meeting this threshold indicates a baseline competency in utilizing PostgreSQL's event-driven capabilities. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-30 09:34 |
MIT License |
View |
| 810 |
Insufficient number of user-defined views |
This query assesses the use of abstraction layers within the database schema. It verifies that there are at least 4 user-defined views present. Views are essential for simplifying complex queries, restricting data access, and presenting specific data perspectives to applications. Meeting this threshold indicates a sufficient implementation of data abstraction and query encapsulation. |
Problem detection |
INFORMATION_SCHEMA only |
2025-11-30 09:38 |
MIT License |
View |
| 811 |
Insufficient number of user-defined foreign tables |
This query assesses the utilization of PostgreSQL's Foreign Data Wrapper (FDW) capabilities. It verifies the existence of at least 2 user-defined foreign tables within the database schema. This requirement ensures that the implemented solution demonstrates the ability to integrate and query data from external sources, extending the data model beyond local storage. |
Problem detection |
INFORMATION_SCHEMA only |
2025-11-30 09:31 |
MIT License |
View |
| 812 |
Insufficient number of user-defined domains |
This query assesses the utilization of user-defined domains within the database schema. It verifies a specific structural requirement: the database must contain at least one user-defined domain that is referenced by at least two distinct non-foreign key columns in base tables. This metric serves as an indicator of proper domain reuse and data type standardization. The query validates whether the schema design effectively leverages domains to enforce consistent data definitions across multiple attributes. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-20 11:47 |
MIT License |
View |
| 813 |
Inconsistent regex character class syntax usage |
This query audits regular expressions across the database to detect inconsistent syntax when defining character classes. It specifically checks for the concurrent usage of Perl-style shorthand notation (e.g., \s, \d) and POSIX character classes (e.g., [[:space:]], [[:digit:]]). While often functionally overlapping, these syntaxes may have subtle behavioral differences depending on locale and engine versions. The presence of both styles within a single database indicates a lack of coding standards, reducing readability and increasing maintenance complexity. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-20 13:12 |
MIT License |
View |
| 814 |
Find mixed usage of \w and [[:alnum:]] regex syntax |
This query audits regular expressions within the database to detect inconsistent syntax for matching alphanumeric characters. It checks for the concurrent use of both the Perl-style shorthand \w and the POSIX character class [[:alnum:]]. While these are often functionally similar, their exact behavior can differ based on locale settings (e.g., \w may include underscores while [[:alnum:]] does not). Using both styles within the same codebase indicates a lack of a clear standard, which can lead to maintainability issues and subtle, locale-dependent bugs. Standardizing on a single, well-understood syntax is recommended for clarity and predictability. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-15 11:11 |
MIT License |
View |
| 815 |
Inconsistent digit character class syntax in regular expressions |
This query audits regular expressions within the database to detect syntactical inconsistencies in identifying numeric digits. It checks for the concurrent use of disparate character class notations: range-based ([0-9]), Perl-style shorthand (\d), and POSIX character classes ([[:digit:]]). While these are often functionally equivalent for standard ASCII digits, mixing multiple syntaxes within a single codebase indicates a lack of standardization, which reduces code readability and increases cognitive load during maintenance. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-25 17:13 |
MIT License |
View |
| 816 |
Inconsistent prefixing of specific (non-generic) column names |
This query audits the database for inconsistent column naming conventions, specifically focusing on non-generic, domain-specific attributes (excluding primary keys, foreign keys, and generic fields like 'comment'). It detects a hybrid naming strategy: some columns are prefixed with the table name (e.g., employee_salary) and others are not (e.g., hiring_date). This inconsistency suggests a lack of a standardized data dictionary, making query writing unpredictable. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-12-05 10:15 |
MIT License |
View |
| 817 |
Find inconsistency in double underscore/space usage |
This query audits the database schema for inconsistency regarding the use of consecutive separators (double underscores or spaces) within identifiers. It groups objects by type (e.g., CHECK constraints, indexes) and identifies categories where a mixed naming convention exists—specifically, where some identifiers utilize consecutive separators (e.g., idx__name) while others of the same type do not (e.g., idx_name). This variation suggests a lack of enforced coding standards, leading to unpredictability in the schema. The query facilitates a review to establish and enforce a single, uniform naming convention. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-20 13:08 |
MIT License |
View |
| 818 |
Inconsistent syntax for whitespace validation constraints |
This query audits the database schema for syntactical inconsistency in CHECK constraints designed to prohibit empty or whitespace-only strings. It identifies the concurrent use of disparate expression patterns—such as column ~ '\S', column !~ '^[[:space:]]*$', or trim(column) <> ''—to achieve the same functional validation. While these patterns may enforce identical logical rules, the lack of a single, standardized idiom increases cognitive load and maintenance complexity. The query facilitates a review to select one preferred syntax and enforce its uniform application across all relevant columns. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-19 15:00 |
MIT License |
View |
| 819 |
Inconsistent usage of string concatenation methods within or accross different database objects |
This query audits the database schema to assess the consistency of string concatenation practices. It identifies the concurrent usage of multiple disparate methods for joining text: the standard concatenation operator (||) and the variadic functions concat() and concat_ws(). While each method has specific use cases (e.g., concat for null safety), indiscriminate mixing of these techniques across similar contexts indicates a lack of coding standards. The output facilitates a review to enforce a more uniform approach where appropriate. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-12-13 14:49 |
MIT License |
View |
| 820 |
The same CHECK has a different name in different places (2) |
This query audits the database schema to enforce a uniform naming strategy for CHECK constraints. It identifies inconsistencies where constraints enforcing identical Boolean expressions are named using disparate patterns across different tables. To isolate the naming pattern from specific object identifiers, the query normalizes the constraint names by substituting the actual table name with the generic token TABLE. This allows it to detect violations of the "Clean Code" principle of consistency—flagging cases where the same logical rule is implemented with a specific naming convention in one context (e.g., chk_TABLE_column) but a different convention in another (e.g., TABLE_column_check). |
Problem detection |
system catalog base tables only |
2025-11-27 10:17 |
MIT License |
View |