Обсуждение: Example. Foreign Keys Constraints. Wrong Columns

The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/18/ddl-constraints.html
Description:

https://www.postgresql.org/docs/current/ddl-constraints.html#DDL-CONSTRAINTS-FK

In the last example of this section it seems the `users` table is referenced
wrong.

```sql
CREATE TABLE users (
    tenant_id integer REFERENCES tenants ON DELETE CASCADE,
    user_id integer NOT NULL,
    PRIMARY KEY (tenant_id, user_id)
);

CREATE TABLE posts (
    tenant_id integer REFERENCES tenants ON DELETE CASCADE,
    post_id integer NOT NULL,
    author_id integer,
    PRIMARY KEY (tenant_id, post_id),
    FOREIGN KEY (tenant_id, author_id) REFERENCES users ON DELETE SET NULL
(author_id)
);
```

In this example `FOREIGN KEY (tenant_id, author_id) REFERENCES users ON
DELETE SET NULL (author_id)` implies that `users` table columns are named
`(tenant_id, author_id)` but in fact `users` table does not have a
`author_id` column.

That line should be probably like this because `users` tables has a
`user_id` column instead of `author_id`

```sql
CREATE TABLE posts (
    # ...
    FOREIGN KEY (tenant_id, author_id) REFERENCES users (tenant_id, user_id)
ON DELETE SET NULL (author_id)
);
```

David G. Johnston wrote:
> On Wed, Apr 15, 2026 at 7:51 AM PG Doc comments form <noreply@postgresql.org>
> wrote:
> 
>> The following documentation comment has been logged on the website:
>>
>> Page: https://www.postgresql.org/docs/18/ddl-constraints.html
>> Description:
>>
>>
>> https://www.postgresql.org/docs/current/ddl-constraints.html#DDL-CONSTRAINTS-FK
>>
>>
> Given that users has:
> 
>>     PRIMARY KEY (tenant_id, user_id)
>>
>>
> This:
> 
> 
>>     FOREIGN KEY (tenant_id, author_id) REFERENCES users ON DELETE SET NULL
>> (author_id)
>>
>>
> And this:
> 
> 
>>     FOREIGN KEY (tenant_id, author_id) REFERENCES users (tenant_id,
>> user_id)
>> ON DELETE SET NULL (author_id)
>>
> 
> Produce an identical outcome.
> 
> The absence of a column list on the former causes the system to look at the
> primary key for the named table and use its column list - which is
> (tenant_id, user_id), same as the later explicit version.
> 
> David J.
> 

Thanks for explanation.

I think "columns mapping" (just how I call it in this example) makes
this example slightly non-intuitive, and reflects a less-common use case.
Would it help to change `author_id` to `user_id` as a more
straightforward case?

Yushu Chen