| 841 |
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 |
| 842 |
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 |
| 843 |
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 |
| 844 |
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 |
| 845 |
Too generic names (columns) (aggregate view) |
This query generates a frequency distribution of semantically weak column identifiers within the schema. It aggregates the occurrences of generic names (e.g., id, type, data) to quantify their prevalence across the database. This statistical view serves as a prioritization tool for refactoring, highlighting the most ubiquitous violations of naming conventions that contribute to schema ambiguity. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2026-01-21 09:15 |
MIT License |
View |
| 846 |
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 |
| 847 |
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 |
| 848 |
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 |
| 849 |
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 |
| 850 |
Perhaps the type of a base table column should be TIMESTAMPTZ |
This query identifies all base table columns defined with the timestamp without time 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:21 |
MIT License |
View |
| 851 |
Checking the text maximum length with CHECK |
This query identifies all base table columns that enforce a maximum value length through the use of a CHECK constraint. It specifically searches for constraint definitions that contain length-calculating functions (such as length(), char_length(), or similar patterns) to provide a comprehensive list of all columns where data length is explicitly managed by a business rule at the database level. |
General |
system catalog base tables only |
2025-11-13 13:05 |
MIT License |
View |
| 852 |
Avoid using length function |
This query identifies all expressions that use the non-standard length() function. Although length() is a functional synonym for char_length() in PostgreSQL, its use is discouraged for two primary reasons: char_length() is the SQL-standard function, and length() has different semantics in other database systems (e.g., returning byte length in MySQL). To enhance code portability and prevent semantic ambiguity for developers, this query flags all instances of length() to encourage standardization on the char_length() function. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-13 12:53 |
MIT License |
View |
| 853 |
Usage of the non-standard now() function |
This query identifies all expressions that use the non-standard now() function. In PostgreSQL, now() is a historical, non-standard alias for the SQL-standard current_timestamp. While they are functionally identical within PostgreSQL (both returning the transaction start timestamp as a TIMESTAMPTZ), the use of current_timestamp is strongly preferred for reasons of code portability and adherence to standards. Standardizing on current_timestamp ensures the code is universally understood and easier to maintain or migrate to other database systems. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-15 10:01 |
MIT License |
View |
| 854 |
Foreign keys with ON DELETE CASCADE |
This query identifies all foreign key constraints that use ON DELETE CASCADE for the purpose of a design audit. The results must be manually reviewed to verify that each use case correctly implements a specific conceptual relationship. According to design principles, ON DELETE CASCADE is only appropriate for implementing generalization hierarchies (is-a relationships), compositions (strong ownership), or the existential dependency of a non-main entity on a main entity. Any usage outside of these patterns is considered a potential design flaw. |
General |
system catalog base tables only |
2025-11-08 10:51 |
MIT License |
View |
| 855 |
Find views that can accept data modification statements |
This query identifies all views against which data modification statements (INSERT, UPDATE, DELETE) can be executed without raising an error. It evaluates the is_insertable_into and is_updatable attributes to detect both "naturally" updatable views (where PostgreSQL automatically maps changes to base tables) and views made updatable via the rewrite rule system (specifically DO INSTEAD rules). Notably, this definition encompasses views defined with DO INSTEAD NOTHING rules; while such views do not physically modify data, they are technically considered updatable because they accept DML statements without failure. |
General |
INFORMATION_SCHEMA only |
2025-12-13 12:34 |
MIT License |
View |
| 856 |
CHECK constraints are inconsistent with DEFAULT values |
This query identifies a logical contradiction between data validation rules and default value definitions. It flags CHECK constraints involving two columns where both columns share the same DEFAULT value, yet the constraint enforces a strict inequality (e.g., col1 < col2) or non-equality (col1 <> col2). This configuration is logically flawed because attempting to insert a row using the default values for both columns will result in an immediate constraint violation (as X < X evaluates to false). This renders the default values mutually exclusive and unusable in practice. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-12-14 13:28 |
MIT License |
View |
| 857 |
Redundant sequence usage privileges (missing table insert rights) |
This query identifies a logical mismatch in access control lists (ACLs). It flags cases where a role is granted USAGE privilege on a sequence (allowing the generation of values via nextval) but lacks the INSERT privilege on the table associated with that sequence. Since the primary purpose of such a sequence is to generate surrogate keys for new rows, possessing the right to generate IDs without the right to insert rows renders the sequence privilege functionally useless. This violates the principle of least privilege and should be revoked to minimize the attack surface. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2026-01-21 11:50 |
MIT License |
View |
| 858 |
Perhaps an unsuitable use of CHAR(n) type in base tables (based on check constraints) |
This query identifies a logical redundancy and likely data type misuse by finding CHAR columns that have a CHECK constraint on their value's length. The CHAR(n) data type is fixed-width and space-padded, meaning any non-NULL value will have a character length of exactly n. Therefore, a CHECK constraint on length is either superfluous (if it checks <= n) or will always fail (if it checks < n). This pattern indicates that the developer intended to store a variable-length string with a maximum length, for which the VARCHAR data type is the correct and more efficient choice. |
Problem detection |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-13 15:08 |
MIT License |
View |
| 859 |
Columns with BOOLEAN type that do have a good name |
This query identifies and lists all BOOLEAN columns that conform to the established predicate-based naming convention. It returns columns whose names begin with one of the approved semantic prefixes: is_, has_, can_, or on_. The output serves as a report of schema components that correctly adhere to best practices for clarity and self-documentation, turning column names into unambiguous true/false questions (e.g., is_agreement instead of agreed). |
General |
INFORMATION_SCHEMA+system catalog base tables |
2025-11-13 13:58 |
MIT License |
View |
| 860 |
Coupling of distinct entity lifecycles via shared state classifiers |
This query identifies a potential domain modeling flaw where multiple distinct entity tables reference a single, shared state classifier table. According to robust design principles, each main entity type should define its own independent state machine and lifecycle. Sharing a classifier creates undesirable coupling; even if the state vocabularies (e.g., 'Active', 'Inactive') appear identical currently, the business logic for distinct entities is likely to diverge over time. Furthermore, reliance on a universal state table often indicates an under-analyzed domain model utilizing overly generic state transitions. |
Problem detection |
system catalog base tables only |
2026-01-19 17:36 |
MIT License |
View |