PostgreSQL extensions

Every extension begins with an explicit registration token:

let mut extensions = rent::extension::ExtensionRegistry::default();
let pgvector = extensions.register_pack::<PgVector>()?;

That token gates the extension's functions, types, operators, indexes, migrations, and higher-level clients. Manifests describe PostgreSQL compatibility, installation schema, privileges, preload libraries, dependencies, provider enablement, and tested upgrade paths.

Operational extensions such as pgmq expose async, database-bound clients. Query-oriented extensions expose typed expressions that compose with Rent's SQL AST and generated predicates.

Share an application transaction

Pass the generated client to a registered pack to use its connection context. Inside a transaction closure, pass tx so application writes and extension calls commit or roll back together:

use rent_ext_pgmq::PgmqClientExt;

client
    .transaction_app(async |tx| -> anyhow::Result<()> {
        let post = tx
            .create_post()
            .title("A new post")
            .body("Hello!")
            .published(false)
            .author_id(author_id)
            .save()
            .await?;

        pgmq
            .client(tx)
            .queue("post_events")
            .send(serde_json::json!({ "post_id": post.id }))
            .await?;

        Ok(())
    })
    .await?;

Create the queue during application setup. A registered pack can also bind directly to a DatabasePool for independent operations. Binding to a transaction client preserves its connection and session settings; using that client after commit or rollback returns a closed-transaction error. Database row-level security still applies. Arbitrary extension SQL does not infer Rent entity policies; check application authorization before issuing administrative calls or enqueueing privileged work.

Scalar and row-set results

The shared extension client decodes native SQL values. query_i32, query_i64, query_string, query_bytes, query_f32, query_f64, and query_bool return None for no row or SQL NULL and reject multiple rows. Use query_scalar_result::<T> when you need to distinguish ScalarResult::NoRow, ScalarResult::Null, and ScalarResult::Value(value). query_required::<T> requires one non-NULL value. Type mismatches are errors, not automatic coercions. SQL NULL and the JSON value null remain distinct in typed JSON scalar results.

Use query_json for row sets and execute for operations whose result is intentionally ignored.

Before planning an extension migration, verify the destination server and hosting policy:

rent extension check --provider self-hosted

After installation or upgrade, inspect the versions and database objects that are actually present:

rent extension status

Both commands support --format json for deployment automation. See the check and status command guides for full output and provider options.

Choose a capability

• Application infrastructure: pgmq queues, pg_cron schedules, and pg_net HTTP
• Search and discovery: pgvector, ParadeDB pg_search, and pg_trgm
• Location and time: PostGIS and TimescaleDB
• Data modeling and integrity: citext, uuid-ossp, pg_jsonschema, and pg_partman
• Security and auditing: pgcrypto and pgAudit

Each extension page explains the underlying project, when to use it, the typed Rent API, deployment requirements, and the executable example that keeps the guide tested.