| # | Name | Goal | Type | Data source | Last update ▼ | License | |
|---|---|---|---|---|---|---|---|
| 21 | 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 |
| 22 | Routine for reading data uses another routine to read some data | This query analyzes the call graph of user-defined routines to identify nested data retrieval patterns. It flags routines that are operationally read-only (performing no DML) but rely on invoking other routines to access additional data. This indicates a layered architecture where data access logic is encapsulated and chained. Identifying these routines is essential for performance profiling, as the total cost of execution is distributed across the call stack rather than being contained within a single procedure body. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-12-26 11:48 | MIT License | View |
| 23 | All derived tables that use joining tables | This query identifies complex derived tables (views and materialized views) that perform data integration operations. Specifically, it filters for views whose definition involves joining two or more distinct tables. This distinguishes non-trivial views—which encapsulate relationship logic and data aggregation—from simple projection views that merely mirror a single base table. The result highlights the core reporting and data integration layer of the schema. | General | INFORMATION_SCHEMA+system catalog base tables | 2025-12-26 10:02 | MIT License | View |
| 24 | Updatable views missing WITH CHECK OPTION | This query identifies automatically updatable views that lack the WITH CHECK OPTION clause. Without this constraint, it is possible to perform INSERT or UPDATE operations through the view that create rows which do not satisfy the view's defining predicate (the WHERE clause). This results in "phantom" modifications where the new or updated data is successfully committed to the base table but is immediately excluded from the view's result set. Enforcing WITH CHECK OPTION ensures that all data modifications performed through the view remain visible within the view. | Problem detection | INFORMATION_SCHEMA only | 2025-12-26 09:54 | MIT License | View |
| 25 | Redundant DO INSTEAD NOTHING rules on naturally non-updatable views | This query identifies redundant rewrite rules within the database schema. It targets views that are inherently non-updatable (due to the presence of aggregates, joins, or set operations) but are nevertheless defined with a DO INSTEAD NOTHING rule. Since the PostgreSQL engine cannot perform DML operations on such views natively, the view is effectively read-only by definition. Consequently, the explicit rule serves no functional purpose in preventing data modification and represents superfluous schema metadata. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-12-26 09:52 | MIT License | View |
| 26 | Function-based index usage mismatch in user-defined routines | This query identifies performance inefficiencies within user-defined routines caused by a mismatch between the logic in the routine and the definition of function-based indexes. PostgreSQL's query optimizer requires the expression in a query to strictly match the expression defined in the index to trigger an index scan. This query flags instances where a column is indexed using one function (e.g., upper(col)) but is accessed in a routine using a different function (e.g., lower(col)). Consequently, the optimizer fails to utilize the pre-calculated index, forcing a costly sequential scan. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-12-22 18:42 | MIT License | View |
| 27 | Function-based index usage mismatch in derived tables | This query identifies performance inefficiencies caused by a semantic mismatch between function-based index definitions and their usage within derived tables (views, materialized views). PostgreSQL's query optimizer generally requires the expression in a query to strictly match the expression defined in the index to trigger an index scan. This query flags instances where a column is indexed using one function (e.g., upper(col)) but accessed in a view using a different function (e.g., lower(col)). In such cases, the optimizer cannot utilize the pre-calculated index, resulting in suboptimal execution plans (typically sequential scans). | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-12-22 18:32 | MIT License | View |
| 28 | Perhaps un-trimmed string concatenation in derived tables | This query identifies derived tables (views and materialized views) containing string concatenation logic that introduces potential leading or trailing whitespace. It targets expressions using the concatenation operator (||), concat(), or format() that may inject separators (such as spaces) but lack a surrounding trim() function. This pattern often results in "dangling separators" when one of the concatenated components is null or empty, degrading data quality and presentation. | Problem detection | system catalog base tables only | 2025-12-22 18:28 | MIT License | View |
| 29 | Updating or deleting data in a routine without restricting rows | This query identifies user-defined routines that contain unbounded Data Modification Language (DML) statements. Specifically, it flags routines containing UPDATE or DELETE operations that lack a qualifying WHERE clause. Such statements result in full-table modifications, affecting every row in the target relation. While valid in specific maintenance contexts, this pattern typically represents a critical logic error in transactional code, posing a severe risk of unintended massive data loss or corruption. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-12-20 18:27 | MIT License | View |
| 30 | Quoted numbers indicating poor type selection | This query identifies potential type mismatches by flagging numeric literals enclosed in single quotes. This pattern often triggers unnecessary type casting overhead or indicates a schema design flaw where a textual data type (e.g., VARCHAR) is used to store exclusively numeric data. The recommendation is to either align the data type with the content (e.g., switch to SMALLINT for codes like '1', '2') or ensure the data justifies the textual type by including non-numeric characters. The query explicitly excludes standard SQL error codes found in exception handling routines, as these are syntactically required to be strings. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-12-19 20:29 | MIT License | View |
| 31 | Trigger function comments implying operation implementation rather than validation | This query performs a semantic analysis of trigger function comments to identify potential violations of separation of concerns. It flags triggers whose documentation references explicit database operations (e.g., OP1, OP2) but lacks terminology associated with validation or invariant enforcement (e.g., "check", "ensure", "validate"). This linguistic pattern suggests that the trigger may be improperly implementing the business operation itself (a side effect) rather than serving its primary role as an integrity guardrail, or that the documentation inaccurately reflects the trigger's behavior. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-12-19 20:28 | MIT License | View |
| 32 | Updatable views that have not been turned to read only | This query identifies views that are automatically updatable by the database engine but lack explicit safeguards to prevent data modification. Specifically, it targets views that meet the criteria for auto-updatability (typically simple projections of a single base table) yet are missing an INSTEAD OF trigger or a DO INSTEAD NOTHING rule. Without these mechanisms, any INSERT, UPDATE, or DELETE operation performed against the view will seamlessly propagate to the underlying base table, which may violate the intended read-only design contract. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-12-16 15:31 | MIT License | View |
| 33 | Explicit locking is missing | This query identifies concurrency risks in user-defined routines by flagging INSERT, UPDATE, or DELETE statements that utilize subqueries without a FOR SHARE locking clause. Failure to acquire a shared lock on source rows allows concurrent transactions to modify or delete them between the subquery's execution and the outer operation, potentially leading to data inconsistencies. Routines utilizing the xmin system column are excluded, operating on the assumption that they implement Optimistic Concurrency Control (version checking) and therefore do not require pessimistic locking. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-12-15 12:45 | MIT License | View |
| 34 | Explicit locking is missing (2) (ChatGPT version) | This query identifies concurrency risks in user-defined routines by flagging INSERT, UPDATE, or DELETE statements that utilize subqueries without a FOR SHARE locking clause. Failure to acquire a shared lock on source rows allows concurrent transactions to modify or delete them between the subquery's execution and the outer operation, potentially leading to data inconsistencies. Routines utilizing the xmin system column are excluded, operating on the assumption that they implement Optimistic Concurrency Control (version checking) and therefore do not require pessimistic locking. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-12-15 12:41 | MIT License | View |
| 35 | Optimistic locking routines lacking execution feedback | This query identifies SQL routines that implement optimistic concurrency control via the xmin system column but fail to provide an execution status to the invoker. Specifically, it flags functions that perform UPDATE or DELETE operations filtered by xmin (a version check) but do not return information regarding the operation's success (e.g., a row count or a BOOLEAN status). This is a critical logic flaw; if a concurrency conflict occurs (the row was modified by another transaction), the operation yields zero rows. Without a return value, the failure is silent, leaving the calling application unaware that the data modification did not occur. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-12-15 11:35 | MIT License | View |
| 36 | Input parameters with the same name have different types | This query analyzes the semantic consistency of routine signatures by identifying named input parameters that share an identical identifier but possess divergent data types across different routines. While this pattern is a prerequisite for valid routine overloading (polymorphism), it can also indicate a lack of standardization in the data dictionary. For example, using the parameter name status to denote an INTEGER in one context and TEXT in another creates ambiguity regarding the parameter's expected domain. The query results should be audited to distinguish intentional overloading from naming inconsistencies. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-12-15 11:34 | MIT License | View |
| 37 | Excessive locking with FOR UPDATE in subqueries | This query identifies performance and concurrency bottlenecks caused by excessive locking. It flags INSERT, UPDATE, or DELETE statements that utilize subqueries containing the FOR UPDATE clause. Using FOR UPDATE acquires an exclusive lock, which is semantically inappropriate if the rows in the subquery are merely being read for reference or validation rather than being modified. This practice degrades system concurrency by unnecessarily blocking other transactions. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-12-15 11:26 | MIT License | View |
| 38 | Incorrect field size (based on default values) | This query identifies a potential schema mismatch regarding data precision. It flags base table columns that default to CURRENT_USER or SESSION_USER but define a character length differing from the PostgreSQL standard identifier limit (typically 63 bytes, defined by NAMEDATALEN - 1). Risk (Length < 63): Poses a hard runtime failure risk if a username exceeds the defined length. Inefficiency (Length > 63): Indicates imprecise modeling, as the stored value can technically never exceed the system limit. |
Problem detection | INFORMATION_SCHEMA only | 2025-12-15 11:09 | MIT License | View |
| 39 | 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 |
| 40 | Routines lacking explicit locking (MVCC risks) | This query identifies user-defined routines that may be susceptible to concurrency anomalies due to a lack of explicit locking. PostgreSQL utilizes Multi-Version Concurrency Control (MVCC), where SELECT statements do not block data modification operations. Consequently, routines that read data to inform subsequent modifications without acquiring row-level locks (e.g., FOR UPDATE, FOR SHARE) or using isolation levels higher than READ COMMITTED are prone to race conditions. This query flags such routines for review to ensure transactional integrity is maintained. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-12-14 14:44 | MIT License | View |