| # | Name ▲ | Goal | Type | Data source | Last update | License | |
|---|---|---|---|---|---|---|---|
| 1 | All column DEFAULT values | Find all the default values of base table, view, and foreign table columns. | General | INFORMATION_SCHEMA only | 2025-11-07 10:11 | MIT License | View |
| 2 | All column dynamic DEFAULT values values that do not invoke a sequence | Find all columns that have a dynamic default value, i.e., the value is returned by a function but the function is not for invoking a sequence. | General | INFORMATION_SCHEMA only | 2025-11-07 10:11 | MIT License | View |
| 3 | All columns of a base table have a default value | Find base tables where all the columns have a default value. | Problem detection | INFORMATION_SCHEMA only | 2025-11-07 10:11 | MIT License | View |
| 4 | All column static DEFAULT values | Find all columns that have a static default value, i.e., the value is not returned by a function. | General | INFORMATION_SCHEMA only | 2025-11-07 10:11 | MIT License | View |
| 5 | All declaratively partitioned tables | Find partitioned tables that have been implemented by using the declarative approach. Declarative partitioning is implemented in PostgreSQL starting from PostgreSQL 10. | General | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 10:11 | MIT License | View |
| 6 | All the non-primary key columns are optional | Find base tables where all he non-primary key columns are optional. Avoid too many optional columns. You have to be extra careful with NULLs in case of formulating search conditions of data manipulation statements. | Problem detection | INFORMATION_SCHEMA only | 2025-11-07 10:11 | MIT License | View |
| 7 | Base table columns with the same name and type have different field sizes | Find base table columns that have the same name and type but different field size. | Problem detection | INFORMATION_SCHEMA only | 2025-11-07 10:11 | MIT License | View |
| 8 | Base table columns with the same name have different types | This query identifies semantic inconsistencies across the database schema by finding base table columns that share the same identifier (name) but are defined with differing data types. According to standard data modeling principles, a shared attribute name implies a shared domain concept (e.g., status_code should consistently be an SMALLINT or a CHAR). Discrepancies in data types for homonymous columns (e.g., is_active being BOOLEAN in one table and SMALLINT in another) hinder interoperability, complicate join logic, and confuse developers. | Problem detection | INFORMATION_SCHEMA only | 2025-11-27 11:20 | MIT License | View |
| 9 | Candidate key columns that have a static default value | Find base table columns that are covered by a primary key or a unique constraint and that probably have a static default value. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 10:11 | MIT License | View |
| 10 | Candidate keys where all columns have a static default value | Find base table primary key and unique constraints where all columns probably have a static default value. Candidate key columns (columns that belong to the primary key or to an unique constraints) shouldn't have static default values unless you are enforcing a rule that a table can have at most one row. The point of default values is that system assigns them automatically. There cannot be multiple rows with the same key value. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 10:11 | MIT License | View |
| 11 | Cascading update is not needed (based on surrogate keys) | Find foreign key constraints that reference to a candidate key that is a surrogate key, i.e., its values are generated by the system by using sequence generators. Do not use ON UPDATE CASCADE, ON UPDATE SET NULL, and ON UPDATE SET DEFAULT in case of foreign keys that reference to surrogate keys. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 10:11 | MIT License | View |
| 12 | Chains of ON DELETE CASCADE | This query identifies referential paths (chains of foreign key relationships) where every constraint in the path is configured with ON DELETE CASCADE. The analysis is intended to uncover potential transitive deletion risks, where a single DELETE operation on a root table could trigger a catastrophic, cascading data loss across multiple, deeply-nested tables. The length of such chains is a key indicator of architectural fragility. | General | system catalog base tables only | 2025-11-08 10:50 | MIT License | View |
| 13 | Column names that make joining more difficult (foreign key column name contains the table name) | This query identifies foreign key columns where the identifier diverges from the referenced candidate key solely due to the redundant inclusion of the referencing table's name (as a prefix or suffix). Such naming redundancy precludes the use of the simplified SQL USING syntax in join operations, forcing the use of the more verbose ON clause. Harmonizing these column names (i.e., making the foreign key name identical to the referenced column name) enables more concise query formulation and improves schema readability. | Problem detection | system catalog base tables only | 2025-12-14 11:56 | MIT License | View |
| 14 | Column names that make joining more difficult (foreign key column name equals the referenced table name) | This query identifies foreign key columns where the identifier is identical to the name of the referenced table. This naming pattern typically results in a mismatch between the foreign key column and the referenced primary key column (e.g., a column named department referencing a table department with a primary key department_id). This mismatch precludes the use of the simplified ANSI SQL USING clause in join operations, necessitating the use of the more verbose ON clause. Harmonizing the column name to match the referenced key enables more concise query formulation. The Example: A table Employees has a column named Department that links to the Department table (where the ID is department_id). The Problem: Because the column is named Department and not department_id, you cannot use the shortcut syntax: JOIN Department USING (department_id). You are forced to write: JOIN Department ON Employees.Department = Department.department_id. |
Problem detection | system catalog base tables only | 2025-12-15 11:07 | MIT License | View |
| 15 | Column names that make joining tables more difficult | This query identifies foreign key columns where the identifier differs from the referenced candidate key identifier. It explicitly excludes self-referencing constraints (recursive relationships), where name divergence is structurally mandatory. The primary objective is to identify opportunities to harmonize column names across the schema. Synchronizing the foreign key name with the referenced column name facilitates the use of the ANSI SQL USING clause in join operations (e.g., JOIN t1 USING (client_id)), which is significantly more concise than the explicit ON predicate required when names differ. | Problem detection | system catalog base tables only | 2025-12-14 11:31 | MIT License | View |
| 16 | Column names that make joining tables more difficult (quite similar names) | This query identifies foreign key columns where the identifier deviates slightly from the referenced candidate key, specifically exhibiting a textual difference (Levenshtein distance) of two to four characters. This range typically captures minor prefixes (e.g., fk_) or suffixes that prevent the use of the concise SQL USING syntax in join operations. The query explicitly excludes self-referencing constraints (recursive relationships), where distinct column names are structurally mandatory. Aligning these names allows for cleaner, more readable query formulation. | Problem detection | system catalog base tables only | 2025-12-14 11:29 | MIT License | View |
| 17 | Column names that make joining tables more difficult (table names) | This query identifies foreign key relationships where the identifier of the referenced column diverges from the foreign key column solely due to the inclusion of the table name. It specifically targets cases where the referenced column name is formed by concatenating the target table name with the target column name (e.g., referenced_col = table_name || '_' || fk_col). This naming redundancy prevents the use of the simplified SQL USING syntax for join operations, necessitating verbose ON clauses. Harmonizing these identifiers by standardizing the naming convention improves schema readability and query conciseness. | Problem detection | system catalog base tables only | 2025-12-14 11:53 | MIT License | View |
| 18 | Column names that make joining tables more difficult (very similar names) | This query identifies foreign key columns where the identifier exhibits a minimal textual deviation (exactly one character) from the referenced candidate key. This specific proximity often indicates a typographical error or a singular/plural inconsistency (e.g., user_id vs users_id). The query explicitly excludes self-referencing constraints, where name divergence is structurally mandatory. Harmonizing these names enables the use of the simplified SQL USING syntax for joins, replacing verbose ON clauses and improving query readability. | Problem detection | system catalog base tables only | 2025-12-14 11:30 | MIT License | View |
| 19 | Columns of base tables that hold truth values but do not have a default value (Boolean columns) | Find columns of base tables that have type BOOLEAN but do not have a default value. There are only two truth values - TRUE and FALSE - in case of two-valued logic. Often it should be possible to select one of these as the default value of a column that has BOOLEAN type. | Problem detection | INFORMATION_SCHEMA only | 2025-11-07 10:11 | MIT License | View |
| 20 | Columns of base tables that hold truth values but do not have a default value (non-Boolean columns) | Find non-foreign key columns of base tables that probably (based on the column name) contain values that represent truth values but do not have a default value. There are only two truth values - TRUE and FALSE - in case of two-valued logic. It could be possible to select one of these as the default value in case of the columns. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 10:11 | MIT License | View |