DROP
Remove tables, views, transforms, and experimental storage objects safely.
Tables
DROP TABLE trades;
DROP TABLE IF EXISTS staging_trades;IF EXISTS is supported for DROP TABLE only. It makes a missing table a
successful no-op; it does not suppress dependency or object-kind errors.
Dropping a table removes its current catalog generation and local storage. Prepared plans are invalidated. Active streams over that source receive a terminal source-dropped condition.
Views and transforms
DROP VIEW large_trades;
DROP MATERIALIZED VIEW market_totals;
DROP TRANSFORM copy_trades;Use the object-specific form. The engine rejects, for example, DROP TABLE
against a materialized view and tells the operator which form to use.
Dropping a transform leaves its target table intact.
Storage catalog
DROP STORAGE POLICY trading;
DROP STORAGE POOL fast;
DROP STORAGE RESOURCE nvme0;Storage topology is experimental. Remove table and catalog dependencies, drain resources, and verify placement before dropping these objects.
Dependency safety
NYXDB blocks removal when a maintained or logical view still depends on the
source. List dependents, migrate or remove them explicitly, and retry. Do not
assume an implicit CASCADE.
DROP is an irreversible online schema operation. Take and validate a
current backup, verify the object kind and dependency graph, stop affected
writers and streams, and preserve the recovery point until post-change
validation is complete.
An object recreated with the same name is a new catalog generation. Stale plans and cursors do not silently attach to it.