| 821 |
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 |
| 822 |
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 |
| 823 |
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 |
| 824 |
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 |
| 825 |
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 |
| 826 |
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 |
| 827 |
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 |
| 828 |
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 |
| 829 |
The reference to a database operation is missing from a comment |
This query audits the metadata of user-defined routines to enforce traceability between the implementation and the design specifications. It identifies routines whose comments lack a standardized reference to the specific database operation contract they implement. The query checks for the absence of a required identifier pattern, typically formatted as OP followed by a number (e.g., OP1, OP12). Enforcing this standard ensures that every routine can be mapped back to its originating requirement or business rule. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2026-01-19 16:18 |
MIT License |
View |
| 830 |
Columns with BOOLEAN type that do not have a good name |
This query audits the naming conventions of BOOLEAN columns, enforcing a predicate-based naming convention that begins with is_, has_, can_, or on_. It specifically discourages the use of simple adjectival or past participle forms as column names. For instance, is_agreement is the preferred form over agreed, and on_kinnitatud is preferred over kinnitatud. This standard ensures the column's name is an unambiguous true/false question, which improves schema self-documentation and the readability of SQL queries. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-13 13:56 |
MIT License |
View |
| 831 |
Inconsistent naming of columns with BOOLEAN type |
This query audits the naming conventions of BOOLEAN columns to detect inconsistency. It checks whether the database contains a mix of styles: some boolean columns adhering to a semantic prefix convention (e.g., is_active, has_permission) and others using unprefixed nouns or adjectives (e.g., active, permission). The presence of both styles indicates a lack of a consistent standard, which can reduce schema clarity and predictability for developers. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-13 13:50 |
MIT License |
View |
| 832 |
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 |
| 833 |
Inconsistent CHECK constraints for same-named columns |
This query audits the schema for inconsistent data validation logic. It identifies non-foreign key base table columns that share the same identifier (name) across different tables but enforce a divergent set of single-column CHECK constraints. According to the "Clean Code" principle of consistency, a recurring attribute name (e.g., status_code) implies a shared domain concept and should be subject to identical validity rules globally. Discrepancies indicate that business rules are being applied unevenly, potentially compromising data integrity. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-12-05 19:02 |
MIT License |
View |
| 834 |
Too generic names (columns) |
This query audits the schema for semantically weak column identifiers. It identifies columns named with generic nouns (e.g., data, info, value) or context-free technical terms (e.g., id, type, code, date, fk, pk). Such names violate the principle of self-documenting schema design, as they fail to describe the specific domain attribute being stored. To prevent ambiguity—especially in complex joins—column names should carry sufficient semantic context (e.g., product_type instead of type, creation_date instead of date). |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2026-01-21 09:11 |
MIT License |
View |
| 835 |
Very similar (but not equal) routine names |
This query audits the schema for semantic ambiguity by identifying pairs of routine names (functions, procedures) that exhibit high textual similarity but are not identical. It filters for name pairs with a Levenshtein edit distance of exactly one (less than two, but excluding equality). This specific filter targets typographical errors (e.g., calc_tax vs. calc_tux) or inconsistent singular/plural naming (e.g., get_user vs. get_users), while correctly ignoring valid method overloading where names are identical. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-25 17:29 |
MIT License |
View |
| 836 |
Positional argument usage in multi-parameter routine calls |
This query audits user-defined routine invocations to enforce named parameter notation, specifically targeting calls to routines with multiple input parameters. It identifies invocations using positional notation (e.g., func(a, b)), which couples the calling logic to the specific order of the callee's signature. Crucially, the query excludes invocations of routines that accept a single input parameter. In single-arity contexts, positional notation is structurally unambiguous and widely accepted. The focus is strictly on multi-parameter calls where positional notation increases the risk of argument misalignment during refactoring. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-12-26 12:10 |
MIT License |
View |
| 837 |
Too generic names (columns) (aggregate view)(2) |
This query calculates the total cardinality of semantically weak column identifiers across the entire schema, encompassing both base tables and views. It applies a uniform definition of "generic" (e.g., flagging identifiers like id, type, date) regardless of the underlying object type. By treating table and view columns equivalently, the query provides a holistic metric of naming ambiguity, quantifying the overall prevalence of non-descriptive attributes within the database's public interface. |
Sofware measure |
INFORMATION_SCHEMA+system catalog base tables |
2026-01-21 09:17 |
MIT License |
View |
| 838 |
Find columns that require new lookup tables (based on names and field sizes) |
This query detects data attributes that function as implicit classifiers but lack a corresponding reference entity. It targets textual columns that are not currently constrained (no PK, UK, or FK) but exhibit characteristics of coded data: they either have a very short length (≤ 3 characters) or possess identifiers typical of classifiers (e.g., 'status', 'type'). To reduce false positives, it excludes obvious free-text fields (names, comments) and verifies that no table with a similar name currently exists. This suggests the need to extract these attributes into a new dedicated reference table to enforce domain integrity. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-12-30 09:14 |
MIT License |
View |
| 839 |
ON UPDATE CASCADE is perhaps missing (based on the compensating actions of other foreign key constraints) |
This query detects inconsistencies in the application of ON UPDATE CASCADE for foreign keys referencing the same candidate key. It identifies sets of foreign key constraints where a proper, non-empty subset is configured with ON UPDATE CASCADE. Such a mixed configuration is a functional flaw, as any attempt to update the parent key will be blocked by the non-cascading constraints, rendering the CASCADE action ineffective and preventing the intended data modification. The principle of atomicity requires that for any given key, either all referencing foreign keys have ON UPDATE CASCADE, or none do. |
Problem detection |
system catalog base tables only |
2025-11-08 10:44 |
MIT License |
View |
| 840 |
Intra-object inconsistency in string concatenation methods |
This query detects internal inconsistency within individual database objects (user-defined routines, views, materialized views). It flags objects that utilize both the standard concatenation operator (||) and variadic concatenation functions (concat() or concat_ws()) within the same definition body. Mixing null-unsafe operators (||) with null-safe functions (concat) in a single routine suggests a lack of coherent logic or an incomplete refactoring effort, potentially leading to confusing behavior regarding NULL handling. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-27 12:27 |
MIT License |
View |