# PostgreSQL come autorità dei metadati dei database dei workspace

ThothII userà un Metadata Catalog PostgreSQL interno per conservare, per ogni workspace, la
struttura fisica acquisita interrogando il relativo database e i metadati semantici generati con
l'AI. Ogni Workspace Database conserverà un `workspace_id` obbligatorio e univoco: questo realizza
l'associazione uno-a-uno senza introdurre nel catalogo una tabella Workspace o una foreign key SQL.
Identità e lista dei workspace resteranno autorevoli in `thoth-workspaces.yaml`; il servizio
validerà il riferimento contro quel catalogo. `schema/annotations.yaml` verrà sostituito come input
del core in uno step successivo; l'interfaccia e il lifecycle amministrativi resteranno separati dal
workflow NL→SQL.

## Considered Options

- Conservare `annotations.yaml` come fonte di verità avrebbe mantenuto il revisionamento Git, ma
  non avrebbe fornito il CRUD e il processo di introspezione/generazione richiesti.
- Leggere metadati mutabili dal catalogo senza un confine esplicito avrebbe accoppiato il workflow
  alla disponibilità del nuovo servizio e consentito viste parziali durante gli aggiornamenti.

## Consequences

PSD importerà le annotations esistenti; gli altri workspace genereranno i metadati da zero. Il
cutover futuro dovrà sostituire consapevolmente i consumatori delle annotations e verificarne
l'equivalenza semantica. PostgreSQL può garantire che uno stesso `workspace_id` non sia assegnato a
due database, ma l'esistenza del workspace e la gestione di rename o rimozioni restano responsabilità
del confine applicativo con il catalogo YAML. Le sessioni di test esistenti non sono un vincolo di
migrazione.