PostgreSQL Query Catalog

Find membership relations between roles.

Database must be used by users who have minimal set of privileges for performing tasks. The query helps to find out as to whether some user/role other than PUBLIC and a superuser have rights to use tables and routines of the database.

Find indexes that are identical, i.e., have the same properties, including uniqueness. The query considers all types of indexes, including indexes that have been automatically created to support a constraint and function-based indexes.

Find identifiers that explicitly say that they carry no meaning. Such identifier is called "unnamed" or "anonymous".

Find columns of base tables that based on the default value of the column contain database username. However, the type of the column is not VARCHAR(63) or VARCHAR(128).

Find base table columns that name refers to the possibility that these are used to register dates. Find the columns that do not have an appropriate data type. Column names should reflect the data that is possible to record in the column. For instance, in case of temporal data the column name should indicate as to whether we record dates or timestamps. If the column data type is "date", then the suffix of the column name should be "kp" (Estonian) or "date" (English).

Find base table columns that name refers to the possibility that these are used to register timestamps. Find the columns that do not have an appropriate data type. Column names should reflect the data that is possible to record in the column. For instance, in case of temporal data the column name should indicate as to whether we record dates or timestamps. If the column type is "timestamp", then the suffix of the column name should be "aeg" (Estonian) or "time" (English).

Find table columns with timestamp/date types that data type and dynamically found default value have a different type.

Find table columns with time types, which data type and dynamically found default value have a different type.

Naming of foreign key and referenced candidate key columns should be consistent. It cannot be so that in one table a value is labeled "id" like some surrogate key value and in another it "turns" into human-usable "code" or vice versa. An example:

Person(person_id, name)
Primary Key (person_id)

E_mail_address(e_mail_address_id, person_code, address)
Primary Key (e_mail_address_id)
Foreign key (person_code) References Person (person_id)

Find foreign key constraints where the candidate key columns (belong to a PRIMARY KEY/UNIQUE constraint) and foreign key columns do not have the same data type and field size. Primary key/unique columns and foreign key columns should have the same data type and field size. If, for instance, the primary key column has type INTEGER and foreign key column has type SMALLINT, then one cannot use all the primary key values as foreign key values.

Find parameters of routines that have the same name but a different type. Parameters that have the same name should have, in general, the same data type as well, assuming that the routines, which have the parameters, have different names, i.e., there is no overloading in play.

In case of a chain of relationships between tables (where the primary key and the foreign key have the same columns) the use of ON UPDATE compensating action should be consistent. For instance, in the next example there is inconsistency, because if one changes the person_code in table Person, then the modification does not succeed because it does not cascade to the table Product. It is unclear as to whether it should be possible to change the person_code or not. Person (person_code, surname) Primary key (person_code) Worker(person_code)
Primary key (person_code)
Foreign key (person_code) References Person (person_code) ON UPDATE CASCADE

Product(product_code, registrator)
Primary key (product_code)
Foreign key (registrator) References Worker (person_code) ON UPDATE NO ACTION

Find as to whether there are multiple different types used in case of columns that are meant for registering dates.

Find whether the database uses both CHAR(1) and VARCHAR(1) columns to register a single symbol.

Find as to whether both the numeric type and integer types are used in case of columns that are meant for register data about prices.

Find as to whether in the database there are multiple ways to calculate tsvector values, i.e., by using a generated column and by not using a generated column.

"Names in software are 90 percent of what make software readable. You need to take the time to choose them wisely and keep them relevant. Names are too important to treat carelessly. Names should not cause confusion." (Robert C. Martin, Clean Code) The naming must be consistent. One should avoid mixing synonyms like "seisund", "staatus", and "olek" in Estonian or "state" and "status" in English and stick with one term. For instance, it is a bad practice to use word "state" in table names but word "status" in function names.

Find columns of tables that start with the word comment or komment but end differently (excluding numbers). Return result only if there is more than one naming variant of such columns in the database. For instance, a column has the name "comment" but another "comments".

Find as to whether different precisions/scales are used in case of registering data about sums of money in different columns.