| # | Name | Goal ▲ | Type | Data source | Last update | License | |
|---|---|---|---|---|---|---|---|
| 941 | FILLFACTOR is probably too big | This query identifies base tables with a potentially suboptimal FILLFACTOR setting, targeting those that likely undergo UPDATE operations. A high FILLFACTOR on such tables can lead to poor performance by reducing the likelihood of Heap-Only Tuple (HOT) updates. When a new row version cannot be stored on the same page as the old version, all indexes on the table must be updated with the new tuple's location. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-10 09:08 | MIT License | View |
| 942 | FILLFACTOR is probably too small (2) | This query identifies base tables with a suboptimal FILLFACTOR setting, specifically targeting tables that are heuristically identified as junction tables in a many-to-many relationship. A table is considered a probable junction table if it primarily consists of foreign and primary key columns, with no additional data columns that would suggest UPDATE operations. For these tables, the workload is almost exclusively INSERT and DELETE. Therefore, a FILLFACTOR below 100 serves no performance benefit and results only in wasted storage space and reduced data density. The job of these linking tables is simple: you add a line to connect two things, or you remove the line to disconnect them. You almost never change a line that's already there. The fillfactor setting is used to leave empty space for changes. |
Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-10 09:13 | MIT License | View |
| 943 | B-tree index fillfactor has been explicitly set to 90 | This query identifies B-tree indexes where the FILLFACTOR has been explicitly set to 90. Since 90 is the default FILLFACTOR for B-tree indexes in PostgreSQL, this explicit declaration is superfluous. Removing such redundant settings simplifies the schema definition, improves maintainability, and makes intentionally non-default configurations more apparent. | Problem detection | system catalog base tables only | 2025-11-10 09:15 | MIT License | View |
| 944 | CHECK constraints on TIMESTAMPTZ and TSTZRANGE columns that do not explicitly specify a time zone | This query identifies CHECK constraints on TIMESTAMPTZ and TSTZRANGE columns that use timestamp literals with fixed UTC offsets instead of named time zones. This practice is flagged as a design flaw because fixed offsets do not account for Daylight Saving Time (DST), leading to constraints on both single timestamps and range boundaries that are unable to correctly represent a local time zone's rules throughout the entire year. | Problem detection | INFORMATION_SCHEMA only | 2025-11-07 12:37 | MIT License | View |
| 945 | Range lower bound can be NULL | This query identifies columns of base tables that use a RANGE data type but are configured to permit a NULL lower bound. This highlights ranges that can be "unbounded" on their starting side, which may be unintentional and could impact query logic and data constraints. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 12:03 | MIT License | View |
| 946 | Range upper bound can be NULL | This query identifies columns of base tables that use a RANGE data type but are configured to permit a NULL upper bound. This highlights ranges that can be "unbounded" on their ending side, which may be unintentional and could impact query logic and data constraints. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 12:03 | MIT License | View |
| 947 | Optional base table columns that have a default value that is not the empty string | This query identifies columns that are both NULLable and have a DEFAULT value. This configuration represents a semantic contradiction: the DEFAULT clause implies that a value should always exist for the column, while the absence of a NOT NULL constraint explicitly permits the absence of a value. The presence of a DEFAULT strongly suggests the column's business logic requires a value, and therefore it should be defined with a NOT NULL constraint to enforce this consistently and make the schema's intent unambiguous. | Problem detection | INFORMATION_SCHEMA only | 2025-11-12 15:00 | MIT License | View |
| 948 | Columns with a range type that require a better name | This query identifies columns with a RANGE data type that violate naming conventions. It flags columns whose names do not semantically suggest a range or period, which can create ambiguity and lead to incorrect assumptions when writing queries. | Problem detection | INFORMATION_SCHEMA only | 2025-11-07 12:30 | MIT License | View |
| 949 | ON UPDATE CASCADE is probably missing (based on column names) | This query identifies foreign key constraints that are likely missing an ON UPDATE CASCADE action. It operates on the heuristic that foreign keys referencing a natural key should permit cascading updates. The query uses a naming convention to identify probable natural keys, specifically flagging foreign key columns having the suffix or prefix "code" on the assumption that such values are user-defined and may require modification. The absence of ON UPDATE CASCADE on these keys can lead to referential integrity violations when the parent key is updated. | Problem detection | system catalog base tables only | 2025-11-08 10:22 | MIT License | View |
| 950 | ON UPDATE CASCADE is probably missing (based on the properties of the referenced column) | This query identifies foreign key constraints that are likely missing an ON UPDATE CASCADE action on what is inferred to be a simple, integer-based natural key. It isolates referenced keys that are single integer columns, are not themselves foreign keys, and, crucially, have no associated sequence generator. This combination strongly indicates a manually managed key whose values might change. The absence of ON UPDATE CASCADE on such relationships can lead to significant data maintenance issues if the natural key value ever needs to be updated. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-08 10:30 | MIT License | View |
| 951 | ON DELETE CASCADE is probably missing (based on the multiplicity of the relationship) | This query identifies foreign key constraints that likely require an ON DELETE CASCADE action. It targets a specific pattern: where the foreign key constraint's columns are identical to a candidate key (Primary Key or Unique constraint) of the same table. This structure implements a one-to-one identifying relationship, where the child entity is existentially dependent on the parent (a weak entity depending on a strong entity). The absence of ON DELETE CASCADE in this scenario is a design flaw, as it prevents the parent row from being deleted and breaks the conceptual model. | Problem detection | system catalog base tables only | 2025-11-08 10:53 | MIT License | View |
| 952 | ON UPDATE CASCADE is probably missing (based on data types) | This query identifies foreign key constraints that likely require an ON UPDATE CASCADE action. It operates on a strong heuristic based on data type: the query flags foreign keys where the column type is neither integer nor uuid and the ON UPDATE CASCADE action is absent. This assumes that non-numeric, non-UUID keys are natural keys (e.g., VARCHAR, CHAR) whose values are meaningful and may need to be updated over time. The absence of ON UPDATE CASCADE on these relationships can impede data maintenance and violate referential integrity upon updates. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-08 10:33 | MIT License | View |
| 953 | ON DELETE CASCADE is probably not needed (based on the relationship type) | This query identifies foreign key constraints that use ON DELETE CASCADE in a non-identifying relationship. A relationship is considered non-identifying if the foreign key columns in the child table are not part of the child table's candidate key. In such cases, the child entity has its own independent identity, and using ON DELETE CASCADE is often a design flaw that can lead to unexpected and catastrophic data loss. | Problem detection | system catalog base tables only | 2025-11-07 20:02 | MIT License | View |
| 954 | ON UPDATE CASCADE is probably not needed (based on column names) | This query identifies foreign key constraints with a superfluous ON UPDATE CASCADE action. It operates on the heuristic that foreign keys referencing surrogate keys should not permit cascading updates, as their values are immutable by definition. The query uses a naming convention to identify probable surrogate keys, specifically flagging foreign key columns with the prefix or suffix "id". The presence of ON UPDATE CASCADE on such keys is not only unnecessary but also misrepresents the nature of the relationship to a schema observer. | Problem detection | system catalog base tables only | 2025-11-08 10:29 | MIT License | View |
| 955 | ON DELETE CASCADE is not needed (based on classifier tables) | This query identifies foreign key constraints with ON DELETE CASCADE that reference classifier tables. Classifier tables hold reference data (e.g., status types, categories), and their rows should not be deleted if they are in use. Applying ON DELETE CASCADE to such a relationship is a critical design flaw, as it creates a direct path for the deletion of a single lookup value to trigger the mass deletion of operational business data. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-08 10:49 | MIT License | View |
| 956 | Incorrect prevention of the empty string or strings that consist of only spaces in a field | This query identifies ineffectual CHECK constraints on base and foreign table columns that incorrectly attempt to prohibit empty or whitespace-only strings using the predicate trim(column_name) IS NOT NULL. Due to PostgreSQL's strict distinction between an empty string ('') and NULL, this check is a tautology; trim('') evaluates to '', and the condition '' IS NOT NULL is always true. The query finds these logically flawed constraints, which fail to provide any data validation and permit the insertion of the exact values they were intended to prevent. | Problem detection | INFORMATION_SCHEMA only | 2025-11-12 14:56 | MIT License | View |
| 957 | Too generic names (many-to-many relationship types that do not have additional attributes) | This query identifies junction tables with semantically redundant names, specifically targeting those whose names contain the word "join". The structure of a many-to-many table (typically two foreign keys forming a composite primary key) is inherently declarative of its role as a join mechanism. Including the word "join" in the name is superfluous and violates the principle of naming based on the entity or relationship being modeled, not the implementation detail. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-10 09:41 | MIT License | View |
| 958 | Permitting in a column only empty strings and strings that consist of whitespace characters | This query identifies logically flawed CHECK constraints on table columns. It specifically searches for constraints that are defined in such a way that they only permit the insertion of an empty string or strings composed entirely of whitespace characters. This behavior is invariably a bug, likely a typo in the constraint's logic (e.g., using ~ instead of !~), which effectively renders the column unusable for storing meaningful data. | Problem detection | INFORMATION_SCHEMA only | 2025-11-09 10:47 | MIT License | View |
| 959 | Base table columns that lack any simple CHECK, i.e, permit empty strings and strings that consist of only whitespace characters | This query identifies non-foreign key columns of base tables with a textual data type that lack any simple (single-column) CHECK constraint. The absence of such constraints indicates a complete lack of column-level validation, creating a risk of low-quality data ingress, including the implicit allowance of empty or whitespace-only strings. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-09 10:23 | MIT License | View |
| 960 | Base table columns permitting empty strings and strings that consist of only whitespace characters (2) | This query identifies non-foreign key columns with a textual data type that lack essential validation. It specifically targets columns that are missing both of the following fundamental checks:
The absence of such comprehensive validation increases the risk of poor data quality and potential application-level bugs. |
Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-12 14:50 | MIT License | View |