the database system to store any value associated with such external writes temporarily in a special relation in the database The text below is from the book Database System Concepts by Silberschatz.
Why the values associated with external writes need to be stored in a special relation in the database? Can't we behave with these values like other values?

We must be cautious when dealing with observable external writes, such as writes
to a user’s screen, or sending email. Once such a write has occurred, it cannot be
erased, since it may have been seen external to the database system. Most systems
allow such writes to take place only after the transaction has entered the committed
state. One way to implement such a scheme is for the database system to store any value
associated with such external writes temporarily in a special relation in the database,
and to performthe actual writes only after the transaction enters the committed state. If
the system should fail after the transaction has entered the committed state, but before
it could complete the external writes, the database system will carry out the external
writes (using the data in non-volatile storage) when the system is restarted.
Can't we behave with these values like other values?

That's exactly what is suggested in your quote: you store data to be written externally in a (special) relation, because they are special, transient entities.
Suppose you have a workflow system in which a task is assigned to a user by updating its user_id attribute (&quot;internal write&quot;). It also needs to send an email notification (an external write) to that user. These two happen asynchronously, but the external one must always happen after the internal one is persisted. You update the task record as usual (nothing &quot;fake&quot; about it) and create a new outbound_email entity with whatever information is relevant. When the task update is committed, you process outbound_email and delete the transient record.
This works pretty much like a write-ahead log for external actions: you first create a record for the action, then perform that action at an appropriate moment, then discard the log record as it is no longer needed. If the flow is interrupted, you replay the &quot;log&quot; to recover.