Why can I create a table with PRIMARY KEY on a nullable column?

Question

The following code creates a table without raising any errors:

CREATE TABLE test(
ID INTEGER NULL,
CONSTRAINT PK_test PRIMARY KEY(ID)
)

Not

Answer 1

Because the PRIMARY KEY makes the column NOT NULL automatically. I quote the manual here:

The primary key constraint specifies that a column or columns of a table can contain only unique (non-duplicate), nonnull values. Technically, PRIMARY KEY is merely a combination of UNIQUE and NOT NULL.

Bold emphasis mine.

I ran a test to confirm that (against my former belief!) NOT NULL is completely redundant in combination with a PRIMARY KEY constraint (in the current implementation, up to version 9.5). The NOT NULL constraint stays after you drop the PK constraint, irregardless of an explicit NOT NULL clause at creation time.

db=# CREATE TEMP TABLE foo (foo_id int PRIMARY KEY);
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index "foo_pkey" for table "foo"
CREATE TABLE

db=# ALTER TABLE foo DROP CONSTRAINT foo_pkey;
ALTER TABLE

db=# \d foo
   table »pg_temp_4.foo«
 column |  type   | attribute
--------+---------+-----------
 foo_id | integer | not null

Identical behaviour if NULL is included in the CREATE statement.

However, it still won't hurt to keep NOT NULL redundantly in code repositories if the column is supposed to be NOT NULL. If you later decide to move the pk constraint around, you might forget to mark the column NOT NULL - or whether it even was supposed to be NOT NULL.

There is an item in the Postgres TODO wiki to decouple NOT NULL from the PK constraint. So this might change in future versions:

Move NOT NULL constraint information to pg_constraint

Currently NOT NULL constraints are stored in pg_attribute without any designation of their origins, e.g. primary keys. One manifest problem is that dropping a PRIMARY KEY constraint does not remove the NOT NULL constraint designation. Another issue is that we should probably force NOT NULL to be propagated from parent tables to children, just as CHECK constraints are. (But then does dropping PRIMARY KEY affect children?)

Answer to added question:

Would it not be better if this self-contradictory CREATE TABLE just failed right there?

As explained above, this

foo_id INTEGER NULL PRIMARY KEY

is equivalent to:

foo_id INTEGER PRIMARY KEY

Since NULL is treated as noise word.
And we wouldn't want the latter to fail. So this is not an option.

Answer 2

If memory serves, the docs mention that:

• the null in create table statements is basically a noise word that gets ignored
• the primary key forces a not null and a unique constraint

See:

# create table test (id int null primary key);
CREATE TABLE
# \d test
     Table "public.test"
 Column |  Type   | Modifiers 
--------+---------+-----------
 id     | integer | not null
Indexes:
    "test_pkey" PRIMARY KEY, btree (id)

Answer 3

If as @ErwinBrandstetter said, PRIMARY KEY is merely a combination of UNIQUE and NOT NULL, you can use an UNIQUE constraint without NOT NULL instead of PRIMARY KEY. Example:

CREATE TABLE test(
    id integer,
    CONSTRAINT test_id_key UNIQUE(id)
);

This way you can do things like:

INSERT INTO test (id) VALUES (NULL);
INSERT INTO test (id) VALUES (NULL);
INSERT INTO test (id) VALUES (NULL);