| 841 |
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 |
| 842 |
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 |
| 843 |
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 |
| 844 |
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 |
| 845 |
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 |
| 846 |
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 |
| 847 |
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 |
| 848 |
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 |
| 849 |
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 |
| 850 |
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 |
| 851 |
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 |
| 852 |
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 |
| 853 |
Gratuitous context in the names of parameters |
This query enforces a concise coding style by checking the names of parameters within routines (such as functions or procedures). It finds parameters whose names unnecessarily repeat the name of the routine they belong to. For example, in a function named calculate_invoice, a parameter named calculate_invoice_id would be flagged, as invoice_id is sufficient. A routine cannot have two parameters with the same name, so the shorter name is unambiguous within the context of the routine and results in cleaner, more readable code. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 10:12 |
MIT License |
View |
| 854 |
Enumerated or range types with the same name in different schemas |
This query enforces the Don't Repeat Yorself principle across the database's type system. It identifies ENUM and RANGE types that share the same name but exist in different schemas. This indicates that a conceptual data type has been defined multiple times instead of having a single, canonical definition in a shared schema. Such duplication leads to maintenance overhead and the risk of semantic divergence over time. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 12:38 |
MIT License |
View |
| 855 |
Range upper bound is not restricted |
This query finds range columns of base tables that are missing a safety check on their ending value. It looks for columns where the end of the range can be set to any value, without rules to ensure that value makes sense. This helps ensure that all ranges have proper limits defined for their ending points. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 12:03 |
MIT License |
View |
| 856 |
Range lower bound is not restricted |
This query finds range columns of base tables that are missing a safety check on their starting value. It looks for columns where the start of the range can be set to any value, without rules to ensure that value makes sense. This helps ensure that all ranges have proper limits defined for their starting points. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-07 12:03 |
MIT License |
View |
| 857 |
Base table FILLFACTOR is not 100 |
This query generates a list of all base tables where the FILLFACTOR has been explicitly set to a value other than the default of 100. This non-default setting is a deliberate performance tuning decision, intended to reserve free space within table pages to improve the efficiency of UPDATE operations by facilitating HOT updates. The query provides a comprehensive list for administrators to audit these customizations and verify that they are still necessary and appropriate for the current table workload. |
General |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-10 09:20 |
MIT License |
View |
| 858 |
Foreign keys with ON UPDATE CASCADE |
This query generates a list of all foreign key constraints that are defined with the ON UPDATE CASCADE action. This list must be manually audited to enforce the design principle that this action should be applied exclusively to relationships involving mutable, natural keys. Any instance found referencing an immutable surrogate key should be considered a design flaw and remediated. |
General |
system catalog base tables only |
2025-11-08 10:40 |
MIT License |
View |
| 859 |
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 |
| 860 |
Perhaps the type of a base table column should be TSTZRANGE |
This query identifies all base table columns defined with the range of timestamp without zone data type. Use of this data type is a potential design flaw as it can lead to ambiguity and bugs when handling data from multiple time zones. |
Problem detection |
INFORMATION_SCHEMA only |
2025-11-07 12:24 |
MIT License |
View |