@rebasepro/types 0.17.3 → 0.18.1

package/src/types/schema_version.ts

@@ -1,112 +0,0 @@
-import type { CollectionConfig } from "./collections";
-import { serializeCollections } from "./collection_contract";
-
-/**
- * The schema version stamp.
- *
- * One function, used in three places that must agree or the whole drift-detection
- * story is noise: `rebase build` writes it into a bundle manifest, the runtime
- * serves it from the contract endpoint, and a generated SDK records the value it
- * was built from. If any two of those computed it differently, every client would
- * look permanently out of date.
- *
- * It covers **collections only** — the client's contract is the shape of the
- * data, so editing a hook or a server function must not invalidate every SDK in
- * every repository. That is a deliberate narrowing, not an oversight.
- */
-
-/** Stable stringify: object keys sorted at every level, so key order cannot alter the hash. */
-function canonicalize(value: unknown): string {
-    if (value === null || typeof value !== "object") {
-        return JSON.stringify(value) ?? "null";
-    }
-    if (Array.isArray(value)) {
-        return `[${value.map(canonicalize).join(",")}]`;
-    }
-    const entries = Object.entries(value as Record<string, unknown>)
-        .filter(([, v]) => v !== undefined)
-        .sort(([a], [b]) => (a < b ? -1 : a > b ? 1 : 0));
-    return `{${entries.map(([k, v]) => `${JSON.stringify(k)}:${canonicalize(v)}`).join(",")}}`;
-}
-
-/**
- * Reduce a collection to the parts a generated client is actually built from.
- *
- * The version answers one question — "is this SDK stale?" — so it must change
- * exactly when the generated types could change, and never otherwise. Hashing a
- * whole collection fails both halves of that:
- *
- * - Security rules, callbacks, icons, groups and UI settings do not appear in a
- *   generated client, so including them reports perfectly current SDKs as stale.
- * - Worse, they are not stable *inputs*. The runtime applies default security
- *   rules when it loads collections, so the same source hashed before and after
- *   loading produced two different answers — a build-time stamp that could never
- *   match the server that served it.
- *
- * Codegen reads the slug (for the `Database` key and type names), the properties,
- * and the relations. That is the projection.
- */
-function projectForCodegen(collection: CollectionConfig): Record<string, unknown> {
-    const source = collection as CollectionConfig & {
-        relations?: unknown;
-        subcollections?: CollectionConfig[];
-        path?: string;
-        engine?: unknown;
-        dataSource?: unknown;
-    };
-
-    return {
-        slug: collection.slug ?? source.path,
-        properties: collection.properties,
-        relations: source.relations,
-        // The engine decides whether relations are resolved at all: codegen asks
-        // `getDataSourceCapabilities(collection.engine).supportsRelations`, and an
-        // engine that answers no drops every foreign-key column from the
-        // generated Row/Insert/Update types. Moving a collection to such an
-        // engine is a real change to the generated types, so it has to move the
-        // version. `dataSource` is what resolves to `engine`, so it counts too.
-        engine: source.engine,
-        dataSource: source.dataSource,
-        subcollections: source.subcollections?.map(projectForCodegen)
-    };
-}
-
-/**
- * Compute the canonical string a schema version hashes.
- *
- * Exposed separately so the hashing itself can differ by environment: Node has
- * `crypto`, and callers without it can still compare canonical forms directly.
- */
-export function canonicalSchemaPayload(collections: CollectionConfig[]): string {
-    const projected = serializeCollections(collections)
-        .map(collection => projectForCodegen(collection as CollectionConfig));
-    return canonicalize(projected);
-}
-
-/**
- * A short, non-cryptographic digest of the canonical payload.
- *
- * FNV-1a style, 64 bits, as two 32-bit halves. This is an identity, not a
- * security boundary: nothing trusts a schema version to prove anything, it only
- * answers "is this the same schema as before". A hand-rolled hash keeps this
- * module free of `node:crypto`, so the identical function runs in the browser,
- * in the CLI, and in the runtime — which is the property that actually matters.
- */
-export function computeSchemaVersion(collections: CollectionConfig[]): string {
-    const payload = canonicalSchemaPayload(collections);
-
-    let h1 = 0x811c9dc5;
-    let h2 = 0x01000193;
-
-    for (let i = 0; i < payload.length; i++) {
-        const code = payload.charCodeAt(i);
-        h1 ^= code;
-        // Multiply by the FNV prime using shifts to stay in 32-bit integer math.
-        h1 = (h1 + ((h1 << 1) + (h1 << 4) + (h1 << 7) + (h1 << 8) + (h1 << 24))) >>> 0;
-        h2 ^= code + i;
-        h2 = (h2 + ((h2 << 1) + (h2 << 5) + (h2 << 9) + (h2 << 15) + (h2 << 24))) >>> 0;
-    }
-
-    const hex = (n: number): string => n.toString(16).padStart(8, "0");
-    return `v1:${hex(h1)}${hex(h2)}`;
-}

package/src/types/search.ts

@@ -1,247 +0,0 @@
-/**
- * Opt-in full-text search configuration.
- *
- * ## Why this is opt-in
- *
- * Without a `search` block, `.search()` behaves exactly as it always has: an
- * `ILIKE '%term%'` OR-ed across the collection's top-level, non-enum `string`
- * properties. That default is unchanged and will stay unchanged — declaring
- * this block is the only way to get anything else.
- *
- * The default has three limits that no amount of tuning inside it can fix:
- * it cannot reach inside `map` (JSONB) or `array` properties, it has no notion
- * of relevance, and a leading `%` means it can never use an index. Collections
- * that outgrow those limits declare what they want searched; collections that
- * have not are left completely alone.
- *
- * ## What declaring it does
- *
- * One `tsvector` column, `GENERATED ALWAYS AS … STORED`, plus one GIN index on
- * it. Postgres recomputes the column on every write of a source field, so it
- * cannot drift from the row, and refuses any attempt to write it directly.
- * `.search()` then compiles to `@@ websearch_to_tsquery(…)` against that
- * column, which stems, drops stopwords, AND-es the terms, and ranks.
- *
- * These are stated consequences, not hidden ones: the column and the index
- * appear in generated DDL, in `schema.generated.ts`, and in `rebase db push`
- * output like any other declared object.
- *
- * @example
- * ```ts
- * const talents: PostgresCollectionConfig = {
- *     slug: "talents",
- *     table: "talents",
- *     properties: { … },
- *     search: {
- *         language: "spanish",
- *         unaccent: true,
- *         fields: [
- *             { path: "full_name", weight: "A" },
- *             "location",
- *             "questionnaire.certifications"   // into the JSONB
- *         ]
- *     }
- * };
- * ```
- *
- * @group Search
- */
-export interface SearchConfig {
-    /**
-     * The fields to index, in the author's own words. Nothing is inferred: a
-     * field is searched if and only if it is named here.
-     *
-     * A bare string is shorthand for `{ path, weight: "B" }`.
-     *
-     * A path may address:
-     * - a top-level `string` property — `"full_name"`
-     * - a `string[]` property — `"tags"` (every element is indexed)
-     * - a path into a `map` property — `"questionnaire.certifications"`,
-     *   which indexes every string found at or below that point, including
-     *   nested objects and arrays of strings. JSON *keys* are never indexed,
-     *   only values.
-     *
-     * A path that does not resolve to one of those is a boot-time error, not
-     * a silent omission — a search field you believe is live and is not is the
-     * failure this whole block exists to prevent.
-     */
-    fields: readonly (string | SearchField)[];
-
-    /**
-     * The Postgres text search configuration, which decides stemming and
-     * stopwords. `"spanish"` stems `auditores` to `auditor` and drops `de`;
-     * `"simple"` does neither.
-     *
-     * Defaults to `"simple"`, which is the only choice that is never wrong:
-     * a stemmer applied to the wrong language silently mangles lexemes. Set it
-     * to your content's language to get stemming.
-     *
-     * @default "simple"
-     */
-    language?: string;
-
-    /**
-     * Fold accents before indexing, so `auditoria` matches `auditoría`.
-     *
-     * This is not cosmetic in accented languages. Postgres stems the two
-     * spellings to *different* lexemes — `to_tsvector('spanish', 'auditoría')`
-     * yields `auditor` while `'auditoria'` yields `auditori` — so without this
-     * a query typed without accents misses the rows that carry them, which is
-     * most queries most users type.
-     *
-     * Requires the `unaccent` extension. Boot fails with an explicit message if
-     * it is not installed and cannot be created, rather than quietly indexing
-     * accented text as-is.
-     *
-     * @default false
-     */
-    unaccent?: boolean;
-
-    /**
-     * Name of the generated column holding the `tsvector`.
-     *
-     * Only change this if `search_vector` collides with a column you already
-     * have. It is part of your schema once created: renaming it later is a
-     * column drop and recreate, which rewrites the table.
-     *
-     * @default "search_vector"
-     */
-    column?: string;
-
-    /**
-     * Also match on trigram similarity, so near-misses and typos still rank —
-     * `iso14000` reaching `ISO 14001`, which no amount of stemming will do
-     * because they are simply different lexemes.
-     *
-     * Adds a second generated `text` column and a GIN trigram index alongside
-     * the `tsvector`, and requires the `pg_trgm` extension. Costs write time
-     * and disk; buys the single most common class of failed search.
-     *
-     * Also changes what `_score` means: the trigram similarity is added to
-     * `ts_rank`. It has to be. A typo matches nothing on the exact path, so
-     * every row this finds has a `ts_rank` of zero — ranking by that alone
-     * would order the results arbitrarily, which is the failure `fuzzy` exists
-     * to fix.
-     *
-     * @default false
-     */
-    fuzzy?: boolean;
-
-    /**
-     * Similarity floor for {@link SearchConfig.fuzzy}, between 0 and 1. A row
-     * whose trigram similarity to the query falls below this never matches on
-     * the fuzzy path (it can still match on the exact one).
-     *
-     * Lower admits more typos and more noise. Ignored unless `fuzzy` is set.
-     *
-     * @default 0.3
-     */
-    fuzzyThreshold?: number;
-}
-
-/**
- * One indexed field, with the weight it carries in the ranking.
- *
- * @group Search
- */
-export interface SearchField {
-    /**
-     * Property name, or dotted path into a `map` property.
-     * @see SearchConfig.fields
-     */
-    path: string;
-
-    /**
-     * Postgres weight class. `ts_rank` scores an `A` hit far above a `D` hit,
-     * which is how a name outranks a passing mention in a long description.
-     *
-     * The four classes are Postgres's own and there are exactly four.
-     *
-     * @default "B"
-     */
-    weight?: SearchWeight;
-}
-
-/**
- * Postgres tsvector weight classes, strongest to weakest.
- *
- * @group Search
- */
-export type SearchWeight = "A" | "B" | "C" | "D";
-
-/** The column name used when {@link SearchConfig.column} is not given. */
-export const DEFAULT_SEARCH_COLUMN = "search_vector";
-
-/** The text search configuration used when {@link SearchConfig.language} is not given. */
-export const DEFAULT_SEARCH_LANGUAGE = "simple";
-
-/** The weight a field carries when it does not name one. */
-export const DEFAULT_SEARCH_WEIGHT: SearchWeight = "B";
-
-/** The similarity floor used when {@link SearchConfig.fuzzyThreshold} is not given. */
-export const DEFAULT_FUZZY_THRESHOLD = 0.3;
-
-/**
- * Sort keys a query computes rather than reads from a column.
- *
- * `orderBy` is otherwise typed against the row — `keyof M` — which is exactly
- * right for a column and exactly wrong for relevance: `_score` is produced by
- * the query, so it appears in no generated row type and a project with a
- * generated SDK could not name it. The runtime accepted it, the docs told
- * people to use it, and the types rejected it.
- *
- * Kept as a named union rather than a loose `string` so the other half of the
- * guarantee survives: a typo'd column is still a compile error, and remains a
- * 400 at runtime rather than a silently unsorted list.
- *
- * `_distance` is deliberately not here. A vector search orders by distance on
- * its own and overrides `orderBy` outright, so naming it would imply a choice
- * the caller does not have.
- *
- * @group Search
- */
-export type ComputedSortField = typeof RELEVANCE_SORT_FIELD;
-
-/**
- * The relevance sort key. Valid only on a collection that declares a
- * {@link SearchConfig} *and* on a query that carries a search string; anywhere
- * else it is an unknown field and the request is refused.
- */
-export const RELEVANCE_SORT_FIELD = "_score";
-
-/**
- * One field that matched, and the text around the hit.
- *
- * Returned per row as `_matches` when a query asks for it — see the `explain`
- * option on `.search()`. Answers the question a ranked list otherwise leaves
- * open: *why is this row here?* A candidate surfacing for "iso 14001" because
- * of a certification is a different result from one surfacing because the
- * string appears in a paragraph about something else, and the score alone
- * cannot tell them apart.
- *
- * @group Search
- */
-export interface SearchMatch {
-    /**
-     * The declared field path that matched, exactly as written in
-     * {@link SearchConfig.fields} — e.g. `"questionnaire.certifications"`.
-     * Map it to a label for display; the path is stable, a label is yours.
-     */
-    field: string;
-
-    /**
-     * The matching text, with each hit wrapped in `<mark>…</mark>`.
-     *
-     * Built by Postgres's `ts_headline` over the same normalized text that was
-     * indexed. With {@link SearchConfig.unaccent} on that means the snippet
-     * reads with accents folded — `Auditoria` rather than `Auditoría`. That is
-     * deliberate: `ts_headline` over the *original* text cannot find a hit the
-     * unaccented query produced, so it returns the text with nothing marked at
-     * all. A readable snippet that highlights beats a prettier one that
-     * silently does not.
-     *
-     * Contains markup by construction. Render it as HTML or strip the tags —
-     * do not display it raw, and do not trust it as plain text.
-     */
-    snippet: string;
-}

package/src/types/security_rules.ts

@@ -1,344 +0,0 @@
-/**
- * Row-level security rules for a collection.
- *
- * 325 lines of RLS policy contract that used to sit in the middle of
- * `collections.ts`, between the admin panel's table view-models and the auth
- * collection config. It has no relationship to the shape of a collection — it is
- * the most-read part of the BaaS surface, and it now reads on its own.
- *
- * A rule is compiled to Postgres `CREATE POLICY` DDL and, for the structured
- * flavour, independently evaluated in JavaScript, so the admin UI's idea of what
- * a user may do derives from the same expression the database enforces.
- *
- * Note that rule *names* are not what you write: an unnamed rule compiles to
- * `<table>_<op>_<sha1[0:7]>`, plus an injected `default_admin` baseline. Derive
- * them with `getPolicyNamesForRule`/`getEffectiveSecurityRules` rather than
- * matching on `rule.name`.
- */
-import type { PolicyExpression } from "./policy";
-
-/**
- * SQL operation that a policy applies to.
- * @group Models
- */
-export type SecurityOperation = "select" | "insert" | "update" | "delete" | "all";
-
-/**
- * Flexible Row Level Security rule for a collection.
- *
- * Built on PostgreSQL Row Level Security. Rules can range from
- * simple convenience shortcuts to fully custom SQL expressions, giving you the
- * full power of PostgreSQL Row Level Security.
- *
- * The authenticated user's identity is available in raw SQL via:
- * - `rebase.uid()`   — the user's ID
- * - `rebase.roles()` — comma-separated app role IDs
- * - `rebase.jwt()`   — full JWT claims as JSONB
- *
- * These are set automatically per-transaction by the backend.
- *
- * **How rules combine:** PostgreSQL evaluates all matching policies for an
- * operation. Permissive rules are OR'd together (any one passing is enough).
- * Restrictive rules are AND'd (all must pass). This is standard PostgreSQL RLS behavior.
- *
- * **Mutual exclusivity:** `ownerField`, `access`, structured `condition`, and
- * raw SQL (`using`/`withCheck`) cannot be combined. The type system enforces
- * this — attempting to set conflicting fields will produce a compile-time
- * error.
- *
- * **Which form to reach for:** prefer the structured {@link StructuredSecurityRule}
- * (`condition`/`check`) or the shortcuts (`ownerField`, `access`, `roles`). These
- * are engine-agnostic and evaluated identically by the database and the admin UI,
- * so the UI never shows an action the database will reject. Raw SQL
- * ({@link RawSQLSecurityRule}) keeps full PostgreSQL power but is Postgres-only
- * and server-authoritative (the UI cannot evaluate arbitrary SQL locally).
- *
- * @group Models
- */
-export type SecurityRule =
-    | OwnerSecurityRule
-    | PublicSecurityRule
-    | StructuredSecurityRule
-    | RawSQLSecurityRule
-    | RolesOnlySecurityRule;
-
-/**
- * Shared fields for all SecurityRule variants.
- * @group Models
- */
-export interface SecurityRuleBase {
-    /**
-     * Optional human-readable name for the policy.
-     * If not provided, one will be auto-generated from the table name and operation.
-     * Must be unique per table.
-     *
-     * When using `operations` (array), each generated policy will have the
-     * operation name appended, e.g. `"owner_access_select"`, `"owner_access_update"`.
-     */
-    name?: string;
-
-    /**
-     * Which SQL operation this policy applies to.
-     * Use this when the policy targets a single operation or all operations.
-     *
-     * For multiple specific operations, use `operations` (array) instead.
-     * If neither is specified, defaults to `"all"`.
-     *
-     * @default "all"
-     */
-    operation?: SecurityOperation;
-
-    /**
-     * Array of SQL operations this policy applies to.
-     * The compiler will generate one PostgreSQL policy per operation, sharing
-     * the same configuration.
-     *
-     * This reduces boilerplate when the same rule applies to multiple (but not all)
-     * operations.
-     *
-     * Takes precedence over `operation` (singular) if both are specified.
-     *
-     * @example
-     * // Same rule for select and update
-     * { operations: ["select", "update"], ownerField: "user_id" }
-     *
-     * @example
-     * // Equivalent to operation: "all"
-     * { operations: ["all"], ownerField: "user_id" }
-     */
-    operations?: readonly SecurityOperation[];
-
-    /**
-     * Whether this policy is `"permissive"` (default) or `"restrictive"`.
-     *
-     * - **permissive**: Multiple permissive policies for the same operation are
-     *   OR'd together — if *any* passes, access is granted.
-     * - **restrictive**: Restrictive policies are AND'd with all permissive
-     *   policies — they act as additional gates that *must* also pass.
-     *
-     * This is the standard PostgreSQL RLS model.
-     *
-     * @default "permissive"
-     */
-    mode?: "permissive" | "restrictive";
-
-    /**
-     * **Shortcut.** Restrict this rule to users that have one of these
-     * application-level roles.
-     *
-     * **Important:** These are NOT native PostgreSQL database roles — names
-     * like `public`, `anon` or `authenticated` belong to {@link pgRoles} and
-     * produce a condition no user can satisfy if used here. These are
-     * application roles managed by Rebase, stored as an inline `roles TEXT[]`
-     * column on the users table, and injected into each transaction as
-     * `app.user_roles` — which `rebase.roles()` reads.
-     *
-     * There is no roles registry: a role exists once it is assigned to a user.
-     *
-     * Generates a safe array-overlap condition — the user passes if they hold
-     * *any* of the listed roles:
-     *   `string_to_array(rebase.roles(), ',') && ARRAY['<role1>', '<role2>']`
-     *
-     * (Note: this is a true set intersection, NOT a regex/substring match, so
-     * a role named `admin` never matches `nonadmin` or `superadmin`.)
-     *
-     * Can be combined with `ownerField`, `access`, `condition`, or raw
-     * `using`/`withCheck`. When combined, the role check is AND'd with the
-     * other condition.
-     *
-     * @example
-     * // Only admins can delete
-     * { operation: "delete", roles: ["admin"] }
-     *
-     * @example
-     * // Admins have unfiltered read access to all rows
-     * { operation: "select", roles: ["admin"], using: "true" }
-     */
-    roles?: readonly string[];
-
-    // ── Advanced: native PostgreSQL role targeting ───────────────────────
-
-    /**
-     * **Advanced.** Native PostgreSQL database roles the policy applies to.
-     *
-     * By default, all generated policies target the `public` role (i.e.
-     * every database connection). This is correct for most setups where
-     * a single database role is used for all connections.
-     *
-     * **Important:** These are NOT the same as the application-level
-     * {@link roles} (admin, editor, viewer, etc.) — those are enforced in the
-     * USING/WITH CHECK clauses via `rebase.roles()`. This field controls the
-     * PostgreSQL `TO` clause in `CREATE POLICY ... TO role_name`.
-     *
-     * Use this if you have dedicated PostgreSQL roles (e.g. `app_read`,
-     * `app_write`) and want policies to target specific ones.
-     *
-     * @default ["public"]
-     *
-     * @example
-     * // Only apply this policy when connected as `app_role`
-     * { operation: "select", access: "public", pgRoles: ["app_role"] }
-     */
-    pgRoles?: readonly string[];
-}
-
-/**
- * Security rule that grants access based on row ownership.
- * Generates a USING/WITH CHECK clause like: `<column> = rebase.uid()`
- *
- * Cannot be combined with `using`, `withCheck`, or `access`.
- *
- * @example
- * { operation: "all", ownerField: "user_id" }
- *
- * @group Models
- */
-export interface OwnerSecurityRule extends SecurityRuleBase {
-    /** The property (column) that stores the owner's user ID. */
-    ownerField: string;
-    access?: never;
-    using?: never;
-    withCheck?: never;
-    condition?: never;
-    check?: never;
-}
-
-/**
- * Security rule that grants unrestricted row access (no row filtering).
- * Generates `USING (true)`.
- *
- * This means "no row-level filter", NOT "anonymous/unauthenticated access".
- * Authentication is still enforced at the API layer — this only controls which
- * *rows* authenticated users can see.
- *
- * Cannot be combined with `using`, `withCheck`, or `ownerField`.
- *
- * @example
- * // Public read (any authenticated user sees all rows)
- * { operation: "select", access: "public" }
- *
- * @group Models
- */
-export interface PublicSecurityRule extends SecurityRuleBase {
-    /** Grant unrestricted row access for this operation. */
-    access: "public";
-    ownerField?: never;
-    using?: never;
-    withCheck?: never;
-    condition?: never;
-    check?: never;
-}
-
-/**
- * Security rule expressed as a structured, engine-agnostic
- * {@link PolicyExpression}. This is the **recommended** way to write a
- * non-trivial condition: it compiles to PostgreSQL `USING`/`WITH CHECK` SQL
- * *and* is evaluated identically by the admin UI, so the UI can never show an
- * action the database will reject.
- *
- * Cannot be combined with `ownerField`, `access`, or raw `using`/`withCheck`.
- *
- * @example
- * // Owner, or any user holding the `moderator` role
- * {
- *   operation: "update",
- *   condition: policy.or(
- *       policy.compare(policy.field("user_id"), "eq", policy.authUid()),
- *       policy.rolesOverlap(["moderator"])
- *   )
- * }
- *
- * @group Models
- */
-export interface StructuredSecurityRule extends SecurityRuleBase {
-    /**
-     * Structured condition for the `USING` clause — which *existing* rows are
-     * visible / can be modified / deleted (SELECT, UPDATE, DELETE).
-     */
-    condition: PolicyExpression;
-
-    /**
-     * Structured condition for the `WITH CHECK` clause — which *new/updated*
-     * row values are allowed (INSERT, UPDATE). Defaults to `condition` when
-     * omitted, mirroring PostgreSQL's own behavior.
-     */
-    check?: PolicyExpression;
-
-    ownerField?: never;
-    access?: never;
-    using?: never;
-    withCheck?: never;
-}
-
-/**
- * Security rule using raw SQL expressions for full PostgreSQL RLS power.
- *
- * **Postgres-only and server-authoritative.** Arbitrary SQL cannot be
- * evaluated by the admin UI, so a rule using this form is treated as *unknown*
- * client-side (never silently allowed) and its effect on visible actions is
- * reflected from the server. For conditions that should also drive the UI
- * precisely, prefer the structured {@link StructuredSecurityRule}.
- *
- * Cannot be combined with `ownerField`, `access`, or structured `condition`.
- *
- * You can reference columns via `{column_name}` which will be resolved to
- * `table.column_name` in the generated Drizzle code.
- *
- * @example
- * // Rows published in the last 30 days are visible
- * { operation: "select", using: "{published_at} > now() - interval '30 days'" }
- *
- * @example
- * // Only the owner, or users with 'moderator' role
- * {
- *   operation: "select",
- *   using: "{user_id} = rebase.uid() OR rebase.roles() ~ 'moderator'"
- * }
- *
- * @group Models
- */
-export interface RawSQLSecurityRule extends SecurityRuleBase {
-    /**
-     * Raw SQL expression for the `USING` clause.
-     * This controls which *existing* rows are visible / can be modified / deleted.
-     * Applied to SELECT, UPDATE, and DELETE.
-     */
-    using: string;
-
-    /**
-     * Raw SQL expression for the `WITH CHECK` clause.
-     * This controls which *new/updated* row values are allowed.
-     * Applied to INSERT and UPDATE.
-     *
-     * If not provided on INSERT/UPDATE policies, falls back to `using`
-     * (which matches PostgreSQL's own default behavior).
-     */
-    withCheck?: string;
-
-    ownerField?: never;
-    access?: never;
-    condition?: never;
-    check?: never;
-}
-
-/**
- * Security rule that only filters by application roles, without any
- * row-level condition (USING/WITH CHECK).
- *
- * Useful for simple "only admins can access this table" rules where
- * no per-row filtering is needed.
- *
- * @example
- * // Only admins can delete
- * { operation: "delete", roles: ["admin"] }
- *
- * @group Models
- */
-export interface RolesOnlySecurityRule extends SecurityRuleBase {
-    ownerField?: never;
-    access?: never;
-    using?: never;
-    withCheck?: never;
-    condition?: never;
-    check?: never;
-}