Question

Why couldn’t the definition of REFERENCES be expanded to also support table constraints, and then FOREIGN KEY could be eliminated from SQL?

It’s clear that the difference between REFERENCES and FOREIGN KEY is that REFERENCES is a column constraint, whereas FOREIGN KEY is a table constraint.

For example, create table T (A int, B int, C int, primary key (A,B), (B,C) references T(A,B) on delete cascade) is not legal, because you need to have foreign key before (B, C), because the constraint refers to multiple columns.

Answer 1

SQL is verbose and highly explicit. Why? There will be no good answer except for the fact that the SQL-1992 standard already defined things this way:

11.8 <referential constraint definition>

[...]

Format

     <referential constraint definition> ::=
          FOREIGN KEY <left paren> <referencing columns> <right paren>
            <references specification>

     <references specification> ::=
          REFERENCES <referenced table and columns>
            [ MATCH <match type> ]
            [ <referential triggered action> ]

FOREIGN KEY is just a mandatory keyword in a DDL statement. That’s it. One could argue that a FOREIGN KEY constraint shouldn’t be a higher-class citizen compared to a UNIQUE or CHECK constraint, hence they all need their appropriate keyword

11.6 <table constraint definition>

[...]

    <table constraint> ::=
            <unique constraint definition>
          | <referential constraint definition>
          | <check constraint definition>