Summary
Per the resolution of #322, `VACUUM` on a doltlite database now aliases to `SELECT dolt_gc()` (`src/vacuum.c:170-196`). Two SQLite VACUUM behaviors remain unsupported and return errors:
```sql
VACUUM INTO 'other.db';
-- Error: VACUUM INTO is not supported for doltlite databases
BEGIN;
VACUUM;
-- Error: cannot VACUUM from within a transaction
```
The first is a real gap (SQLite supports copying the vacuumed DB to a separate file). The second matches SQLite's own behavior and is intentional.
VACUUM INTO
Implementing this would mean writing the current chunk store to a new file at a different path. `dolt_gc()` already does this internally via a `*-gc-tmp` rename — exposing that destination as user-supplied would be the cleanest hook.
Closest mechanism today: `dolt_clone('file:///path/to/dest.db')` from a fresh DB. Not a drop-in replacement for `VACUUM INTO` (different argument shape, and it requires the dest to be empty), but functionally equivalent.
Not blocking anything
Both gaps are documented errors with clear messages, not silent data loss. Filing as a tracker; no urgency unless a real workload hits it.
Summary
Per the resolution of #322, `VACUUM` on a doltlite database now aliases to `SELECT dolt_gc()` (`src/vacuum.c:170-196`). Two SQLite VACUUM behaviors remain unsupported and return errors:
```sql
VACUUM INTO 'other.db';
-- Error: VACUUM INTO is not supported for doltlite databases
BEGIN;
VACUUM;
-- Error: cannot VACUUM from within a transaction
```
The first is a real gap (SQLite supports copying the vacuumed DB to a separate file). The second matches SQLite's own behavior and is intentional.
VACUUM INTO
Implementing this would mean writing the current chunk store to a new file at a different path. `dolt_gc()` already does this internally via a `*-gc-tmp` rename — exposing that destination as user-supplied would be the cleanest hook.
Closest mechanism today: `dolt_clone('file:///path/to/dest.db')` from a fresh DB. Not a drop-in replacement for `VACUUM INTO` (different argument shape, and it requires the dest to be empty), but functionally equivalent.
Not blocking anything
Both gaps are documented errors with clear messages, not silent data loss. Filing as a tracker; no urgency unless a real workload hits it.