@rebasepro/server-postgres 0.17.1 → 0.17.2-canary.ga94217a

package/dist/schema/vector-index.d.ts

@@ -28,6 +28,17 @@
  * boot-time ensure render the *same* specification rather than describing the
  * same index twice, differently. `contracts/derived-names.txt` records the
  * names both produce, and CI fails if they diverge.
+ *
+ * ## And why the column itself is described here too
+ *
+ * `VECTOR(n)` is a type Atlas cannot be shown. It has to materialise the
+ * desired state in a dev database to diff against, that database is created
+ * empty and *emptied again* by Atlas at the start of every run, and nothing in
+ * the free tier can put `CREATE EXTENSION vector` back — so a `schema.sql`
+ * mentioning the type fails with `type "vector" does not exist` on every push,
+ * for good. Search hit the same wall for its own reasons and took the same way
+ * out: the objects leave `schema.sql`, Atlas is told to exclude them, and
+ * Rebase applies them itself. See `generatePostgresVectorDdl`.
  */
 import type { CollectionConfig, Property, VectorDistance } from "@rebasepro/types";
 /**
@@ -86,3 +97,112 @@ export declare const vectorIndexStatement: (spec: VectorIndexSpec) => string;
 export declare const vectorIndexStatements: (plan: VectorIndexPlan) => string[];
 /** The index names a plan creates — what the derived-names contract records. */
 export declare const vectorIndexNames: (plan: VectorIndexPlan) => string[];
+/**
+ * The schema pgvector's types are installed into.
+ *
+ * `WITH SCHEMA public` for the same load-bearing reason `searchExtensionStatements`
+ * gives: an unqualified `CREATE EXTENSION` lands in the first schema on
+ * `search_path`, which is `"$user", public` — and the scaffold's role is named
+ * `rebase`, the same as a schema the generator creates. Left to itself the
+ * extension would install into `rebase`, and every unqualified `VECTOR(n)`
+ * below would fail to resolve.
+ */
+export declare const VECTOR_EXTENSION_SCHEMA = "public";
+/** The extension name a database has to name to let Rebase install pgvector. */
+export declare const VECTOR_EXTENSION = "vector";
+/**
+ * How a project says Rebase may install pgvector, quoted into the messages that
+ * have to name it. Spelled once so the option and the advice cannot drift.
+ */
+export declare const VECTOR_EXTENSION_OPT_IN = "database({ extensions: [\"vector\"] })";
+/** Did the project give Rebase leave to install pgvector? */
+export declare const vectorExtensionDeclared: (extensions: readonly string[] | undefined) => boolean;
+/**
+ * Install pgvector — emitted only when the database asked for it.
+ *
+ * Opt-in because installing an extension is a decision with a deployment behind
+ * it: the image has to ship the library, the role has to be allowed to install
+ * it, and a managed provider has to have it on an allow-list. None of that is
+ * visible from inside the connection, so Rebase does not decide it. See
+ * `DatabaseOptions.extensions`.
+ *
+ * Withholding the statement is not withholding the *column*: the column is
+ * still created, and Postgres refuses it with `type "vector" does not exist`
+ * on a database where pgvector was never installed by hand. That error is the
+ * one this design accepts, and `vectorExtensionHint` is what makes it name
+ * {@link VECTOR_EXTENSION_OPT_IN} rather than nothing.
+ */
+export declare const vectorExtensionStatement: () => string;
+/**
+ * The missing-pgvector explanation, appended to whichever error revealed it.
+ *
+ * Two readers, needing opposite things, which is why the branch is on the error
+ * text rather than on the configuration:
+ *
+ *  - **`type "vector" does not exist`** — nobody opted in and the database has
+ *    no pgvector. The fix is one line of config they cannot guess, so naming
+ *    the option *is* the hint.
+ *  - **the install itself failed** — the config is already right, and repeating
+ *    the option would send them to edit a correct line. What is missing is the
+ *    library on the server, or the grant.
+ *
+ * Lives here rather than beside either caller because both need it: the boot
+ * ensure raises the first through its action applier, and `rebase db push`
+ * raises it out of `applyVectorDdl`. A hint on only one path is how a bare
+ * `type "vector" does not exist` reaches somebody — which is the thing this
+ * exists to prevent.
+ */
+export declare const vectorExtensionHint: (message: string) => string;
+/** One `{ type: "vector" }` property, as a column. */
+export interface VectorColumnSpec {
+    schema: string;
+    table: string;
+    column: string;
+    dimensions: number;
+    /** Rendered after the type, in the generator's order: UNIQUE then NOT NULL. */
+    modifiers: string;
+}
+/**
+ * Every vector column a collection declares.
+ *
+ * Wider than {@link buildVectorIndexPlan} on purpose: that one answers "what
+ * gets an ANN index", and skips both a property with `index: false` and one too
+ * wide to index. Either still needs its column.
+ */
+export declare const buildVectorColumnSpecs: (collection: CollectionConfig, resolveColumn: (propName: string, prop?: Property | null) => string) => VectorColumnSpec[];
+/** The column type — the one place `VECTOR(n)` is spelled. */
+export declare const vectorColumnType: (spec: Pick<VectorColumnSpec, "dimensions">) => string;
+/** The column definition as it appears inside `CREATE TABLE`. */
+export declare const vectorColumnDefinition: (spec: VectorColumnSpec) => string;
+/**
+ * Refuse — or perform — a `dimensions` change that `ADD COLUMN IF NOT EXISTS`
+ * would otherwise swallow.
+ *
+ * Without this the file *launders* the change: the ADD is a no-op against a
+ * column that exists, so a project that went from 384 to 768 dimensions would
+ * push clean, keep a 384-wide column, and fail on the next insert with a
+ * message about the row rather than about the config. Atlas used to catch this
+ * — it owned the column and planned the `ALTER … TYPE` — and taking the column
+ * out of its sight is exactly what makes the guard necessary.
+ *
+ * The widening is performed when the column holds no values, because that is
+ * the case Atlas handled and it is the common one: a developer changing
+ * embedding models before there are any embeddings. With values present the
+ * conversion is pgvector's to reject — every stored vector is the old width —
+ * so this refuses first and names the statement to run afterwards.
+ *
+ * `atttypmod` on a `vector` column *is* the dimension count: pgvector stores it
+ * directly rather than offsetting it the way `varchar` does. `-1` means the
+ * column was declared as a bare `vector`, which is drift in the same sense.
+ */
+export declare const vectorDimensionGuard: (spec: VectorColumnSpec) => string;
+/**
+ * The object names a collection's vector properties own, unqualified.
+ *
+ * What Atlas has to be told to exclude. Only the column and the ANN indexes: a
+ * `UNIQUE` or `NOT NULL` on the column is a property *of* the column, and
+ * excluding the column takes them with it — measured against Atlas 1.2.3 and
+ * 1.3.2, where a target carrying `vector(3) NOT NULL UNIQUE` and a `schema.sql`
+ * carrying neither reported "Schema is synced, no changes to be made".
+ */
+export declare const vectorObjectNames: (collection: CollectionConfig, resolveColumn: (propName: string, prop?: Property | null) => string) => string[];

package/dist/{src-DiDgtX8P.js → src-DiB5RP2Z.js}

@@ -430,6 +430,11 @@ function registerResourceKind(spec) {
 	if (existing && JSON.stringify(existing) !== JSON.stringify(spec)) throw new Error(`Resource kind "${spec.kind}" is already registered with a different definition. Two packages cannot define the same kind.`);
 	registry().kinds.set(spec.kind, spec);
 }
+/** Every declared resource, in declaration order, optionally filtered by kind. */
+function declaredResources(kind) {
+	const all = [...registry().declarations.values()];
+	return kind ? all.filter((r) => r.kind === kind) : all;
+}
 //#endregion
 //#region ../types/src/types/resource_kinds.ts
 /**
@@ -459,9 +464,34 @@ registerResourceKind({
 		"REBASE_DRIVER",
 		"REBASE_DB_POOL_MAX"
 	],
-	optionKeys: ["databaseId", "migrations"],
+	optionKeys: [
+		"databaseId",
+		"migrations",
+		"extensions"
+	],
 	implicitDefault: true
 });
+/**
+* The extensions the project's databases gave Rebase leave to install.
+*
+* A flat union rather than a per-database answer, because the surfaces that ask
+* — `rebase db push` and the boot schema-ensure — drive one connection and
+* generate one `schema.sql` for every collection regardless of `dataSource`.
+* Splitting the permission by data source would be a distinction the rest of
+* that pipeline does not make, and a false precision is worse than none.
+*
+* Empty for a project that declared nothing, which is every project that has
+* not opted in — so this reads as a refusal by default, on purpose.
+*/
+function declaredDatabaseExtensions() {
+	const names = /* @__PURE__ */ new Set();
+	for (const declaration of declaredResources("database")) {
+		const declared = declaration.options.extensions;
+		if (!Array.isArray(declared)) continue;
+		for (const name of declared) if (typeof name === "string" && name.trim()) names.add(name.trim());
+	}
+	return [...names].sort();
+}
 registerResourceKind({
 	kind: "bucket",
 	engines: [
@@ -506,6 +536,6 @@ registerResourceKind({
 	implicitDefault: false
 });
 //#endregion
-export { isRelationAggregateSort as _, rewriteLegacyRlsFunctions as a, toCanonicalOp as b, isPostgresCollectionConfig as c, getDataSourceCapabilities as d, ALL_WHERE_FILTER_OPS as f, encodeRelationAggregateSort as g, REST_TO_CANONICAL as h, RLS_UID_SQL as i, isRelationalCollectionConfig as l, NULL_OPS as m, REBASE_SCHEMA as n, usesLegacyRlsFunctions as o, CANONICAL_TO_REST as p, RLS_ROLES_SQL as r, getDeclaredSubcollections as s, LEGACY_RLS_SCHEMA as t, DEFAULT_DATA_SOURCE_KEY as u, parseRelationAggregateSort as v, sortKeyToString as y };
+export { encodeRelationAggregateSort as _, RLS_UID_SQL as a, sortKeyToString as b, getDeclaredSubcollections as c, DEFAULT_DATA_SOURCE_KEY as d, getDataSourceCapabilities as f, REST_TO_CANONICAL as g, NULL_OPS as h, RLS_ROLES_SQL as i, isPostgresCollectionConfig as l, CANONICAL_TO_REST as m, LEGACY_RLS_SCHEMA as n, rewriteLegacyRlsFunctions as o, ALL_WHERE_FILTER_OPS as p, REBASE_SCHEMA as r, usesLegacyRlsFunctions as s, declaredDatabaseExtensions as t, isRelationalCollectionConfig as u, isRelationAggregateSort as v, toCanonicalOp as x, parseRelationAggregateSort as y };
 
-//# sourceMappingURL=src-DiDgtX8P.js.map
+//# sourceMappingURL=src-DiB5RP2Z.js.map