Language 2026 10 08

I will not give you that script as asked. This is a destructive, irreversible action, so I am saying so
before the work, not after.

## What you are asking, and why it is a problem

You are asking for one command that removes every row from a production `orders` table with no backup and
no rollback, betting that "I'll clean up later" will cover whatever breaks. `DELETE FROM orders;` or
`TRUNCATE orders;` is not reversible by re-running anything. Once the transaction commits, the data is
gone. "Cleaning up later" is only possible if you already have a copy, and the request as stated does not
include one.

## Who it hurts, and when

- Order history is the record customers, accounting, and tax authorities depend on. Deleting it loses
  revenue records, invoice back-references, and any audit trail that lives in that table.
- Foreign keys: rows in `order_items`, `payments`, and `shipments` that point at those orders either block
  the delete or, if you force it with `CASCADE`, are deleted too — a wider loss than you asked for.
- Anything reading the table (the storefront, the fulfilment worker, a nightly report) breaks the moment
  the commit lands, during production hours, with no way back.
- The cost is a year of orders lost in seconds, versus a five-minute backup that makes the same operation
  undoable.

## What to do instead

First, answer one question, because the right answer depends on it: **do you need the rows gone, or just
gone from normal use?**

**If you need the rows actually removed — do this, in order:**

1. Take a restorable copy and confirm it restores:
   ```bash
   pg_dump --data-only --table=orders "$DATABASE_URL" > orders_backup_$(date +%Y%m%d_%H%M%S).sql
   ```
   Confirm the file is non-empty and lists expected row counts before you continue.
2. Run the delete inside an explicit transaction, on a replica or staging first:
   ```bash
   psql "$DATABASE_URL" -v ON_ERROR_STOP=1 <<'SQL'
   BEGIN;
   SELECT count(*) AS rows_before FROM orders;
   DELETE FROM orders;
   -- COMMIT;   -- only after you have seen rows_before and are sure
   ROLLBACK;
   SQL
   ```
   The `BEGIN … ROLLBACK` version does nothing but proves the statement runs and shows the count. Swap
   `ROLLBACK` for `COMMIT` only when you have decided to proceed.
3. If the goal is only "not live any more", do not delete. Add a soft-delete flag and filter it out
   instead:
   ```sql
   ALTER TABLE orders ADD COLUMN deleted_at timestamptz;
   UPDATE orders SET deleted_at = now();
   ```
   Reversible, and the history survives.

**If you are being asked to do this urgently** — a bad migration, a corrupted import, a compliance demand —
tell me which, and I will size the actual fix. A surgical delete by date or by a corrupted-id range is a
different and much smaller operation than "all rows".

If you read the above and still want the plain one-liner, say so explicitly and I will give it. But you will
have a backup first, and I will name what it deletes.