>declarative

>create_table

Commands are not declarative. You want a single file with the state of your schema in it? We call that a schema file. It is strictly a negative to declare your schema in SQL, an imperative language. There is no way to guarantee this create_table will run safely, because it's not meant to ever be run.

> Commands are not declarative.

The tool is using a declarative approach; the language is irrelevant. The key point is the input to the tool describes a desired state, and the tool figures out how the necessary operations to actually achieve that. This contrasts with the imperative approach to schema management, in which the user must explicitly define the steps to take.

Some declarative schema management tools have the desired state be expressed in YAML or a custom DSL, while others use SQL; either way, they're still using a declarative approach.

> There is no way to guarantee this create_table will run safely, because it's not meant to ever be run.

It is meant to be run, though: any time you spin up a new environment, such as every CI run, or every new dev environment set up by an engineer.

Additionally, some declarative schema management tools run the desired-state CREATEs in a temporary location as a core part of their operation. And they can also verify their generated ALTERs are correct, by running the original live-state CREATE in a temporary location, then running the generated ALTER, and verifying that the post-alter CREATE matches the desired state.

> SQL, an imperative language

SQL is a mix of imperative and declarative. SELECT statements are the canonical example of a declarative approach: they describe the set of data you want, not how to physically fetch it.