Goal This query identifies leaf base tables (tables with no inheriting children) that possess one or more UNIQUE constraints but lack a defined PRIMARY KEY. It is a standard database design best practice to designate one candidate key as the primary key for every table, treating remaining candidate keys as alternate keys. Parent tables are specifically excluded from this check because, in PostgreSQL inheritance, primary keys do not enforce global uniqueness across the entire table hierarchy. Parent tables often serve as abstract templates, meaning primary keys are properly defined only on their respective child tables.
Type Problem detection Each row in the result could represent a flaw in the design
Reliability High Few or no false-positive results
License MIT (opens in new tab)
Data Source INFORMATION_SCHEMA+system catalog
SQL Query
SELECT A.table_schema, A.table_name 
FROM INFORMATION_SCHEMA.tables A
INNER JOIN INFORMATION_SCHEMA.schemata B
  ON A.table_schema = B.schema_name
WHERE (A.table_schema, A.table_name) NOT IN 
  (SELECT table_schema, table_name FROM INFORMATION_SCHEMA.table_constraints
   WHERE constraint_type IN ('PRIMARY KEY'))
AND (A.table_schema, A.table_name) IN 
  (SELECT table_schema, table_name FROM INFORMATION_SCHEMA.table_constraints
   WHERE constraint_type IN ('UNIQUE'))
AND A.table_type = 'BASE TABLE'
AND (A.table_schema = 'public' OR B.schema_owner <> 'postgres')


AND NOT EXISTS (
    SELECT 1
    FROM pg_inherits i
    INNER JOIN pg_class c ON c.oid = i.inhparent
    INNER JOIN pg_namespace n ON n.oid = c.relnamespace
    WHERE n.nspname = A.table_schema 
      AND c.relname = A.table_name
)

ORDER BY A.table_schema, A.table_name;

Fixing Suggestion

To resolve this issue, review the flagged table and determine which of the existing unique constraints (or candidate keys) best serves as the primary identifier. Promote that candidate key to a primary key using the ALTER TABLE ... ADD PRIMARY KEY statement. Ensure that all other candidate keys are properly maintained as alternate keys using UNIQUE and NOT NULL constraints.

Collections

This query belongs to the following collections:

Find problems about integrity constraints

A selection of queries that return information about the state of integrity constraints in the datadabase. Contains all the types of queries - problem detection, software measure, and general overview

Find problems automatically

Queries, that results point to problems in the database. Each query in the collection produces an initial assessment. However, a human reviewer has the final say as to whether there is a problem or not .

NameDescription
Find problems about integrity constraintsA selection of queries that return information about the state of integrity constraints in the datadabase. Contains all the types of queries - problem detection, software measure, and general overview
Find problems automaticallyQueries, that results point to problems in the database. Each query in the collection produces an initial assessment. However, a human reviewer has the final say as to whether there is a problem or not .

Categories

This query is classified under the following categories:

Inconsistencies

Queries of this catergory provide information about inconsistencies of solving the same problem in different places.

Uniqueness

Queries of this category provide information about uniqueness constraints (PRIMARY KEY, UNIQUE, EXCLUDE) as well as unique indexes.

Validity and completeness

Queries of this category provide information about whether database design represents the world (domain) correctly (validity) and whether database design captures all the information about the world (domain) that is correct and relevant (completeness).

NameDescription
InconsistenciesQueries of this catergory provide information about inconsistencies of solving the same problem in different places.
UniquenessQueries of this category provide information about uniqueness constraints (PRIMARY KEY, UNIQUE, EXCLUDE) as well as unique indexes.
Validity and completenessQueries of this category provide information about whether database design represents the world (domain) correctly (validity) and whether database design captures all the information about the world (domain) that is correct and relevant (completeness).

Further reading and related materials:

The corresponding code smell in case of cleaning code is "G11: Inconsistency". (Robert C. Martin, Clean Code)
Rule 4 in: Delplanque, J., Etien, A., Auverlot, O., Mens, T., Anquetil, N., Ducasse, S.: CodeCritics applied to database schema: Challenges and first results. In: 2017 IEEE 24th International Conference on Software Analysis, Evolution and Reengineering (SANER), pp. 432-436. IEEE, (2017).
Reference
The corresponding code smell in case of cleaning code is "G11: Inconsistency". (Robert C. Martin, Clean Code)
Rule 4 in: Delplanque, J., Etien, A., Auverlot, O., Mens, T., Anquetil, N., Ducasse, S.: CodeCritics applied to database schema: Challenges and first results. In: 2017 IEEE 24th International Conference on Software Analysis, Evolution and Reengineering (SANER), pp. 432-436. IEEE, (2017).