PostgreSQL Query Catalog

Find expressions that use LIKE predicate for precise comparison.

Find expressions that use LIKE (including ILIKE) predicate with a regular expression patterns. In a LIKE pattern one can use only _ and % metasymbols to construct a pattern.

Find expressions that use LIKE predicate witout a pattern that contains at least one % or _ sign.

Find mandatory (NOT NULL) base table columns that name, column type, and field size refers to the possibility that these are used to register large textual values like comments, descriptions, and explanations.

Find base tables that implement many-to-many relationship types that do not permit repeating relationships. More specifically find tables that have two or more foreign keys and all the columns of the table are either foreign key columns or a surrogate key column. It could be that during the system analysis a mistake has been made and some attributes of the entity type that represents the relationship type have not been discovered.

Find base tables that implement many-to-many relationship types that do not permit repeating relationships. More specifically find tables that have two or more foreign keys and all the columns of the table belong to a foreign key. In addition, all the table columns must be covered by a primary key or unique constraint. It could be that during the system analysis a mistake has been made and some attributes of the entity type that represents the relationship type have not been discovered.

This query identifies junction tables (implementing a binary relationship via two foreign keys) whose names are simple concatenations of the parent table names (e.g., Course_Lecturer). This naming style is flagged as a design smell because it merely describes the physical implementation rather than the conceptual relationship being modeled. The recommended best practice is to rename such tables to reflect the domain concept they represent. For instance, the relationship between Course and Lecturer should be named after the activity it represents, such as Teaching or Course_Assignment.

This query identifies junction tables (implementing a binary relationship via two foreign keys) whose names are simple concatenations of the parent table names, often with minor variations (e.g., Courses_Lecturer). This naming convention is a design smell as it describes the physical implementation rather than the conceptual relationship being modeled. The recommended best practice is to rename such tables to reflect the domain concept they represent. For instance, the relationship between Course and Lecturer should be named after the activity it represents, such as Teaching or Course_Assignment.

Find derived tables that subquery contains terms "foo", "bar", "foobar", or "baz".

Find names of database objects that contain terms "foo", "bar", "foobar", or "baz".

Find routines that subquery contains terms "foo", "bar", "foobar", or "baz".

Find a routine that's only task is to invoke another routine. If a routine performs only one action, delegating work to another routine, why does it exist at all?

This query identifies base table columns whose name and data type suggest they store row registration or last modification times, but which lack a default value. In good database design, such audit timestamp columns should typically have a default value (like CURRENT_TIMESTAMP or now()) to ensure the time is recorded automatically.

If a user has a privilege to use a schema object, then the user must also have the usage privilege on the schema that contains the object.

Use the same mechanism of generating surrogate key values throughout the database. The use of SERIAL notation/explicitly creating a sequence generator and declaration of a column as an identity column will cause the creation of an external and internal sequence generator, respectively. Nevertheless, one should try to stick with using one of the mechanisms in order to cause less confusion. "If you do something a certain way, do all similar things in the same way." (Robert C. Martin, Clean Code)

Declaring a column to have the type TEXT or the type VARCHAR (without the maximum number of characters) has the same end result in terms of what data can be recorded in the column. Nevertheless, one should try to stick with using one of the type names in order to cause less confusion. "If you do something a certain way, do all similar things in the same way." (Robert C. Martin, Clean Code)

This query identifies multiple-column CHECK constraints that explicitly check for NULL values. In general, constraint definitions should be kept as simple as possible. Because a NULL value causes a logical condition to evaluate to UNKNOWN—and CHECK constraints inherently allow rows that evaluate to either TRUE or UNKNOWN—there is usually no need to explicitly allow missing values. For instance, instead of writing CHECK (last_update_time IS NULL OR last_update_time >= creation_time), the constraint should simply be written as CHECK (last_update_time >= creation_time). However, a valid exception exists for implication rules (P ⇒ Q), which can be rewritten as NOT (P) OR Q. For example, the constraint CHECK (NOT (product IS NOT NULL) OR service IS NULL) properly enforces the rule that if a product is present, the service must be NULL. Such logical constructs are entirely appropriate.

Find base tables where multiple columns are associated with a sequence generator. Do not create unnecessary sequence generators. If one uses in a table a surrogate key, then it is enough to have one column where the values are generated by using a (external or internal) sequence generator.

Code should be as compact as possible and system should make as little work as necessary in order to solve a task. Thus, instead of deleting different rows of the same table with different DELETE statements one should try to do it with one statement. The query excludes routines where IF statement is used.

Find SQL functions that have multiple statements with the RETURNING clause.