# ProcruSQL

## Goals

Declarative, Config declares how a schema should look like.

In most cases, procrusql should figure out what it has to do.

It must be possible to supply custom code, either because procrusql
doesn't know what to do or because it can be done in a cleaner or faster
way.

Data migrations must be possible, for example:
    * A new column is filled with data from an old old column.
    * A new table is filled with data from existing tables
    * New data is inserted into the database. This may require using
      intermediate results (e.g. inserting data into into a master table
      returns a new PK which is then used for inserts as the FK in a
      detail table)

Need some kind of dependency system (similar to make). 
For example, if a migration requires creating a new table, copying data
from an existing table and then dropping the old column, we have to make
sure that happens in the right order.

Syntax should be easy to read and write

Syntax should be diff-friendly

All changes should be done in a single transaction.

It should be possible to use multiple database connections (for example,
installing functions in an untrusted language requires a privileged
user). Obviously, if we have several connections, we can't have a single
transaction.

## Non-Goals

Reverting changes (instead apply the old config again).

Performance. I expect the typical configuration to be small (dozens of
tables and hundreds of records, not hundreds of tables and millions of
records) and the use cases to be infrequent (a few deployments per day,
not many per second).

## Problems

Is the order of operations always the same or is it sometimes necessary
to do things in a different order depending on the current state?

## Random ideas

I think we should have empty nodes which are just used to group dependencies,
e.g. something like `table_x_complete` which depends on `table_x` and all its
columns, contraints, indexes, data, etc. so that other nodes can just depend on
`table_x_complete` and don't have to bother about the details.

I don't have a good ideas for data changes yet. For example I may want
to change the value of a (non-PK) column for one or more rows. Easy in
SQL, not easy in a generic way without reinventing SQL. 
Idea for the simple case: data_update key={} new={}.
Maybe allow arbitrary SQL for the complex case. But must be idempotent.