PostgreSQL Query Catalog

The naming must be consistent. Find foreign key constraints where the candidate key column and foreign key column names have different prefixes. Thus, for instance, one cannot use USING syntax for joining the tables.

The precision of a timestamp type of a column must be able to accommodate all the fractional seconds of the default value of the column. Find table columns with the type timestamp without time zone(m) or timestamp with time zone(m) that have a default value LOCALTIMESTAMP(n) or CURRENT_TIMESTAMP(n) WHERE n>m.

There should not be cycles in hierarchies meaning that the parent must always be specified. In this case a parent must reference to a child or to itself, otherwise it cannot be registered.

The return value of a function cannot be left undefined. If control reaches the end of the top-level block of the function without hitting a RETURN statement, a run-time error will occur. This restriction does not apply to functions with output parameters and functions returning void, however. In those cases a RETURN statement is automatically executed if the top-level block finishes. It also does not apply to trigger functions that only task is to raise an exception.

The same domain should not have multiple CHECK constraints with exactly the same Boolean expression. Do remember that the same task can be solved in SQL usually in multiple different ways. Thus, the exact copies are not the only possible duplication.

The same table should not have multiple CHECK constraints with exactly the same Boolean expression. Do remember that the same task can be solved in SQL usually in multiple different ways. Thus, the exact copies are not the only possible duplication.

The schema size is the sum of the sizes of all tables in the schema.

These triggers should be enabled because otherwise some important functionality regarding constraints like enforcing referential integrity does not work.

The table size is the sum of the total size of the simple columns and the total size of the complex columns in the table. In case of SQL databases large base tables in terms of number of columns could be a side effect of the problems with cloned columns or multiple columns for the same attribute. A base table with a low normalization level, which is meant to hold data that corresponds to multiple entity types has typically also relatively large number of columns compared with other base tables. Thus, the normalization level of base tables with a large number of columns should be checked as well.

The value that is returned by a function should depend on something. If you do not have anything meaningful to return (for instance, the function always returns true, false, NULL, or the same number), then write VOID instead of the return type.

This metric represents the number of foreign keys in a base table.

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.

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.

This query assesses the database's adherence to modern SQL standards regarding procedural code. It verifies whether the schema contains a minimum of 3 user-defined, non-trigger routines that are specifically written in the SQL language and utilize a SQL-standard body (defined using BEGIN ATOMIC ... END). This excludes routines written in PL/pgSQL or those using the legacy string-literal body definition. The metric ensures a baseline adoption of the standardized, portable syntax for SQL routines introduced in newer PostgreSQL versions.

This query assesses the extent of active logic implementation within the database schema. It verifies that there are at least 3 user-defined triggers or rewrite rules present in the database. These objects represent automated tasks that for example enforce complex integrity constraints. Meeting this threshold indicates a baseline competency in utilizing PostgreSQL's event-driven capabilities.

This query assesses the extent of active logic implementation within the database schema. It verifies that there are user-defined triggers or rewrite rules present for at least 3 tasks. These objects represent automated tasks that for example enforce complex integrity constraints. Meeting this threshold indicates a baseline competency in utilizing PostgreSQL's event-driven capabilities.

This query assesses the use of abstraction layers within the database schema. It verifies that there are at least 4 user-defined views present. Views are essential for simplifying complex queries, restricting data access, and presenting specific data perspectives to applications. Meeting this threshold indicates a sufficient implementation of data abstraction and query encapsulation.

This query assesses the utilization of PostgreSQL's Foreign Data Wrapper (FDW) capabilities. It verifies the existence of at least 2 user-defined foreign tables within the database schema. This requirement ensures that the implemented solution demonstrates the ability to integrate and query data from external sources, extending the data model beyond local storage.

This query assesses the utilization of user-defined domains within the database schema. It verifies a specific structural requirement: the database must contain at least one user-defined domain that is referenced by at least two distinct non-foreign key columns in base tables. This metric serves as an indicator of proper domain reuse and data type standardization. The query validates whether the schema design effectively leverages domains to enforce consistent data definitions across multiple attributes.

This query audits regular expressions across the database to detect inconsistent syntax when defining character classes. It specifically checks for the concurrent usage of Perl-style shorthand notation (e.g., \s, \d) and POSIX character classes (e.g., [[:space:]], [[:digit:]]). While often functionally overlapping, these syntaxes may have subtle behavioral differences depending on locale and engine versions. The presence of both styles within a single database indicates a lack of coding standards, reducing readability and increasing maintenance complexity.