Filter Queries
Found 15 queries.
- All the queries about database objects contain a subcondition to exclude from the result information about the system catalog.
- Although the statements use SQL constructs (common table expressions; NOT in subqueries) that could cause performance problems in case of large datasets it shouldn't be a problem in case of relatively small amount of data, which is in the system catalog of a database.
- Statistics about the catalog content and project home in GitHub that has additional information.
#1. Case insensitive search
INFORMATION_SCHEMA+system catalog base tablesRefers to the column pg_proc.prokind and thus works starting from PostgreSQL 11. Find user-defined routines and derived tables (views/materialized views) that have a subquery with case insensitive search (by using the upper or lower function or ILIKE predicate or (?i) modifier of a regular expression pattern).
#2. Derived tables with ranking
INFORMATION_SCHEMA+system catalog base tablesFind views and materialized views that use rank and dense_rank window functions.
#3. Find || operations missing coalesce() protection
INFORMATION_SCHEMA+system catalog base tablesThis query identifies potential null-propagation defects in user-defined routines and views. It targets subqueries utilizing the standard concatenation operator (||) where operands are not protected by a coalesce() function. In PostgreSQL, the operation string || NULL yields NULL, causing the entire result to vanish if any component is missing. This behavior is often unintentional. The query flags these risky patterns, suggesting remediation via explicit null handling or the adoption of null-safe alternatives like concat(), concat_ws(), or format().
#4. Find useless coalesce, concat, or concat_ws calls with only one argument
INFORMATION_SCHEMA+system catalog base tablesThis query identifies superfluous function calls within routines and views, specifically targeting invocations of coalesce(), concat(), or concat_ws() that are supplied with only a single argument. These functions are variadic and designed to operate on multiple values (e.g., returning the first non-null value or joining strings). When called with a single argument, they function as an identity operation, returning the input unchanged. This pattern indicates either a coding error (missing arguments) or redundant logic that should be removed to simplify the expression.
#5. Function-based index usage mismatch in user-defined routines
INFORMATION_SCHEMA+system catalog base tablesThis 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.
#6. Inconsistency between the type and the default value of a column (date and timestamp values)
INFORMATION_SCHEMA onlyFind table columns with timestamp/date types that data type and dynamically found default value have a different type.
#7. Incorrect reference to a system-defined function in the routine body
INFORMATION_SCHEMA+system catalog base tablesFind user-defined routines that possibly use incorrect name of a system-defined function (currenttimestamp (correct is current_timestamp), currentdate (correct is current_date), currenttime (correct is current_time), local_time (correct is localtime), local_timestamp (correct is localtimestamp),localdate (there is no such function),local_date (there is no such function), sessionuser (correct is session_user), ucase (correct is upper), lcase (correct is lower)). The problem can arise only if the routine uses dynamic SQL. In case of static SQL the DBMS checks the SQL statemen at the creation time and finds out that for instance, SELECT Count(*) AS cnt FROM Emp WHERE hiredate<=currentdate; is incorrect statement because currentdate is not a function name and there is no column currentdate in the table Emp.
#8. Incorrect use of COUNT(*) with outer joins
INFORMATION_SCHEMA+system catalog base tablesThis query identifies user-defined routines and derived tables (views or materialized views) that use the COUNT(*) aggregate function (without a FILTER clause) alongside an OUTER JOIN and a GROUP BY clause. This combination is a common SQL anti-pattern. When grouping with an outer join, COUNT(*) counts the rows themselves, including the NULL-filled rows generated for non-matching records. Consequently, it inaccurately reports a count of 1 for completely empty groups instead of the correct count of 0. To get accurate results, developers should count a specific non-null column from the joined table.
#9. Incorrect use of non-deterministic functions in CHECK constraints
INFORMATION_SCHEMA onlyThis query identifies CHECK constraints that use non-deterministic time functions (such as now or current_date) in a way that causes initially valid data to become invalid over time. For example, a constraint like localtimestamp(0) > end_date is an anti-pattern because advancing time will eventually violate it. However, safe implementations—such as birth_date < CURRENT_DATE—are permitted, because once the condition is met, it remains true indefinitely as time moves forward.
#10. Intra-object inconsistency in string concatenation methods
INFORMATION_SCHEMA+system catalog base tablesThis 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.
#11. Invocation of a system-defined routine without providing any arguments
INFORMATION_SCHEMA+system catalog base tablesFind user-defined routines that contain an invocation of a system-defined function without providing any argument. The query considers all aggregate functions as well as some popular scalar functions.
#12. Perhaps the type of a base table column/domain should be temporal (based on default values)
INFORMATION_SCHEMA onlyFind base table columns and domains that have a textual type but the default value that represents a temporal value (either a static value or invocation of a function that returns such value). Specify for each column/domain a right data type that takes into account expected values in the column/domain.
#13. Unnecessary use of Coalesce
INFORMATION_SCHEMA+system catalog base tablesThis query identifies redundant null-handling logic within string manipulation expressions. It targets the use of explicit coalesce() calls nested inside functions that are already null-safe, such as concat(), concat_ws(), or format(). Since these functions implicitly treat NULL arguments as empty strings (or ignore them), wrapping arguments in coalesce(arg, '') is superfluous. The query deliberately excludes expressions using the standard concatenation operator (||), as coalesce() is legitimately required in that context to prevent null propagation.
#14. Use invocation of a precise function instead of casting in a default value expression
INFORMATION_SCHEMA onlyBe precise and write as little code as possible. Prefer expressions with simple invocations of functions like localtimestamp, current_timestamp, and current_date over expressions like (now())::date. Find table columns that have a default value that casts the type of the returned value of a non-deterministic function (now, localtimestamp, current_timestamp, and current_date).
#15. User-defined routines that have the same name as some system-defined routine.
INFORMATION_SCHEMA+system catalog base tablesAvoid creating user-defined routines that have the same name as some system-defined routine because it may cause confusion.
| # | Name (sorted ascending) | Goal | Type | Data source | Last update | License | Actions |
|---|---|---|---|---|---|---|---|
| 1 | Case insensitive search | Refers to the column pg_proc.prokind and thus works starting from PostgreSQL 11. Find user-defined routines and derived tables (views/materialized views) that have a subquery with case insensitive search (by using the upper or lower function or ILIKE predicate or (?i) modifier of a regular expression pattern). | General | INFORMATION_SCHEMA+system catalog base tables | MIT (opens in new tab) | View (opens in new tab) | |
| 2 | Derived tables with ranking | Find views and materialized views that use rank and dense_rank window functions. | General | INFORMATION_SCHEMA+system catalog base tables | MIT (opens in new tab) | View (opens in new tab) | |
| 3 | Find || operations missing coalesce() protection | This query identifies potential null-propagation defects in user-defined routines and views. It targets subqueries utilizing the standard concatenation operator (||) where operands are not protected by a coalesce() function. In PostgreSQL, the operation string || NULL yields NULL, causing the entire result to vanish if any component is missing. This behavior is often unintentional. The query flags these risky patterns, suggesting remediation via explicit null handling or the adoption of null-safe alternatives like concat(), concat_ws(), or format(). | Problem detection | INFORMATION_SCHEMA+system catalog base tables | MIT (opens in new tab) | View (opens in new tab) | |
| 4 | Find useless coalesce, concat, or concat_ws calls with only one argument | This query identifies superfluous function calls within routines and views, specifically targeting invocations of coalesce(), concat(), or concat_ws() that are supplied with only a single argument. These functions are variadic and designed to operate on multiple values (e.g., returning the first non-null value or joining strings). When called with a single argument, they function as an identity operation, returning the input unchanged. This pattern indicates either a coding error (missing arguments) or redundant logic that should be removed to simplify the expression. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | MIT (opens in new tab) | View (opens in new tab) | |
| 5 | 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 | MIT (opens in new tab) | View (opens in new tab) | |
| 6 | Inconsistency between the type and the default value of a column (date and timestamp values) | Find table columns with timestamp/date types that data type and dynamically found default value have a different type. | Problem detection | INFORMATION_SCHEMA only | MIT (opens in new tab) | View (opens in new tab) | |
| 7 | Incorrect reference to a system-defined function in the routine body | Find user-defined routines that possibly use incorrect name of a system-defined function (currenttimestamp (correct is current_timestamp), currentdate (correct is current_date), currenttime (correct is current_time), local_time (correct is localtime), local_timestamp (correct is localtimestamp),localdate (there is no such function),local_date (there is no such function), sessionuser (correct is session_user), ucase (correct is upper), lcase (correct is lower)). The problem can arise only if the routine uses dynamic SQL. In case of static SQL the DBMS checks the SQL statemen at the creation time and finds out that for instance, SELECT Count(*) AS cnt FROM Emp WHERE hiredate<=currentdate; is incorrect statement because currentdate is not a function name and there is no column currentdate in the table Emp. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | MIT (opens in new tab) | View (opens in new tab) | |
| 8 | Incorrect use of COUNT(*) with outer joins | This query identifies user-defined routines and derived tables (views or materialized views) that use the COUNT(*) aggregate function (without a FILTER clause) alongside an OUTER JOIN and a GROUP BY clause. This combination is a common SQL anti-pattern. When grouping with an outer join, COUNT(*) counts the rows themselves, including the NULL-filled rows generated for non-matching records. Consequently, it inaccurately reports a count of 1 for completely empty groups instead of the correct count of 0. To get accurate results, developers should count a specific non-null column from the joined table. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | MIT (opens in new tab) | View (opens in new tab) | |
| 9 | Incorrect use of non-deterministic functions in CHECK constraints | This query identifies CHECK constraints that use non-deterministic time functions (such as now or current_date) in a way that causes initially valid data to become invalid over time. For example, a constraint like localtimestamp(0) > end_date is an anti-pattern because advancing time will eventually violate it. However, safe implementations—such as birth_date < CURRENT_DATE—are permitted, because once the condition is met, it remains true indefinitely as time moves forward. | Problem detection | INFORMATION_SCHEMA only | MIT (opens in new tab) | View (opens in new tab) | |
| 10 | 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 | MIT (opens in new tab) | View (opens in new tab) | |
| 11 | Invocation of a system-defined routine without providing any arguments | Find user-defined routines that contain an invocation of a system-defined function without providing any argument. The query considers all aggregate functions as well as some popular scalar functions. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | MIT (opens in new tab) | View (opens in new tab) | |
| 12 | Perhaps the type of a base table column/domain should be temporal (based on default values) | Find base table columns and domains that have a textual type but the default value that represents a temporal value (either a static value or invocation of a function that returns such value). Specify for each column/domain a right data type that takes into account expected values in the column/domain. | Problem detection | INFORMATION_SCHEMA only | MIT (opens in new tab) | View (opens in new tab) | |
| 13 | Unnecessary use of Coalesce | This query identifies redundant null-handling logic within string manipulation expressions. It targets the use of explicit coalesce() calls nested inside functions that are already null-safe, such as concat(), concat_ws(), or format(). Since these functions implicitly treat NULL arguments as empty strings (or ignore them), wrapping arguments in coalesce(arg, '') is superfluous. The query deliberately excludes expressions using the standard concatenation operator (||), as coalesce() is legitimately required in that context to prevent null propagation. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | MIT (opens in new tab) | View (opens in new tab) | |
| 14 | Use invocation of a precise function instead of casting in a default value expression | Be precise and write as little code as possible. Prefer expressions with simple invocations of functions like localtimestamp, current_timestamp, and current_date over expressions like (now())::date. Find table columns that have a default value that casts the type of the returned value of a non-deterministic function (now, localtimestamp, current_timestamp, and current_date). | Problem detection | INFORMATION_SCHEMA only | MIT (opens in new tab) | View (opens in new tab) | |
| 15 | User-defined routines that have the same name as some system-defined routine. | Avoid creating user-defined routines that have the same name as some system-defined routine because it may cause confusion. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | MIT (opens in new tab) | View (opens in new tab) |