Chelabase
ManagementTables

The database's tables, views and other relations

GET
/v1/databases/{id}/branches/{branch_id}/objects

Every relation the table API shows in one Postgres database of a branch (system schemas and Chelabase's own objects left out), with its kind, estimated rows, size and whether the table API edits it (editable: ordinary tables only).

Authorization

bearer
AuthorizationBearer <token>

In: header

Path Parameters

id*string

Database id

Formatuuid
branch_id*string

Branch id

Formatuuid

Query Parameters

database?string

The Postgres database; the branch's main database when absent.

Response Body

application/json

application/json

application/json

application/json

application/json

application/json

application/json

application/json

application/json

application/json

curl -X GET "https://example.com/v1/databases/497f6eca-6276-4993-bfeb-53cbbbba6f08/branches/497f6eca-6276-4993-bfeb-53cbbbba6f08/objects"
{  "objects": [    {      "comment": "string",      "data_api_exposed": true,      "editable": true,      "kind": "table",      "name": "string",      "oid": 0,      "owner": "string",      "rls_enabled": true,      "rls_forced": true,      "row_estimate": 0,      "schema": "string",      "total_bytes": 0    }  ]}

Retry a merge that failed while applying POST

For a `failed` merge whose `failed_phase` is `roles`, `enum_add`, `tx` or `online`. Failed in `online`: the plan's transaction is committed and the target changed; only the online steps (concurrent indexes, constraint validation) are left, and the worker continues where it stopped (a valid index is skipped, an invalid one is dropped and rebuilt); the merge is `online` again. If the plan's transaction is no longer on the target, or the target is gone, the merge fails for good. Failed before (`roles`, `enum_add`, `tx`): the worker first checks whether the plan's transaction committed after all (its answer may have been lost); if it did, it goes on to the online steps; if not, the apply runs again from the start, with its checks (a target that changed since the merge was computed makes it `stale`; roles and enum values the first attempt made stay); the merge is `applying` again.

One role's privileges in a Postgres database GET

The privileges `role` holds in one Postgres database of a branch (one of the branch's recorded databases), read as the database owner, a page at a time. Without `schema`: the schemas (paged by name) with the role's schema entries, and the default privileges of those schemas. With `schema`: every table, view, materialized view, partitioned or foreign table, sequence, function and procedure of it (paged), with the role's entries on it and on its columns, the hub's "all rows" policy for the role, its owner and whether an owner run can act as that owner (`owner_settable`). Every entry carries its grantor and grant option. Each schema, object and default-privileges row carries `acl_hash`, a hash over its whole ACL (every grantee; a relation's covers its columns): send it back as `expect_acl` with a schema change. `role=public` reads PUBLIC's entries. Member logins and personal logins aren't listed.