Capability flags for kura backends and pool implementations.

A module that participates in kura's backend story (today: the pool implementation; in 2.0 likely a dedicated backend aggregator) declares the capability set it supports by implementing the optional capabilities/0 callback. Consumers ask kura whether the running backend supports the features they need.

This makes "we don't support that on this backend" a boot error instead of a 3am pager. It is also the discipline that keeps the future multi-backend story honest: a non-SQL backend (Mnesia, Riak) will declare a small capability set, SQL-needing consumers will refuse to start, and there will be no runtime surprises.

Standard capabilities

The capability atom set is open — backends may declare custom flags and consumers may match against them. The standard atoms kura itself cares about:

• returning — INSERT/UPDATE/DELETE ... RETURNING
• jsonb — JSONB column type with operators
• arrays — array column types
• advisory_locks — pg_advisory_lock family
• listen_notify — LISTEN/NOTIFY pubsub
• select_for_update_skip_locked — SELECT ... FOR UPDATE SKIP LOCKED
• partial_indexes — CREATE INDEX ... WHERE
• transactions — BEGIN/COMMIT/ROLLBACK
• savepoints — SAVEPOINT/RELEASE/ROLLBACK TO
• prepared_statements — server-side prepared statements

A module that does not implement capabilities/0 is treated as having the empty capability set. Anything it does support is opaque to kura.

Example

A consumer's supervisor refuses to start if PG-only features are missing:

init(_) ->
    case kura_capabilities:require(kura_pool_pgo, [returning, listen_notify]) of
        ok -> {ok, ...};
        {error, _} = Err -> Err
    end.

A backend declares its set:

-module(kura_pool_pgo).
-behaviour(kura_pool).

capabilities() ->
    [returning, jsonb, arrays, advisory_locks, listen_notify,
     select_for_update_skip_locked, partial_indexes, transactions,
     savepoints, prepared_statements].