@rebasepro/server-postgres 0.14.1 → 0.14.2-canary.g27a129e

package/dist/utils/drizzle-conditions.d.ts

@@ -1,6 +1,6 @@
 import { SQL } from "drizzle-orm";
 import { AnyPgColumn, PgTable } from "drizzle-orm/pg-core";
-import { CollectionConfig, FilterValues, WhereFilterOp, LogicalCondition, FilterCondition, ResolvedRelation, ResolvedForeignKeyOnTarget, ResolvedManyToMany } from "@rebasepro/types";
+import { CollectionConfig, FilterValues, WhereFilterOp, LogicalCondition, FilterCondition, ResolvedRelation, ResolvedBelongsTo, ResolvedForeignKeyOnTarget, ResolvedManyToMany, type RelationAggregateSort } from "@rebasepro/types";
 import { type SearchColumnSpec } from "../schema/search-column";
 import { PostgresCollectionRegistry } from "../collections/PostgresCollectionRegistry";
 /**
@@ -82,6 +82,52 @@ export interface FilterCompilationOptions {
      */
     sourceIdColumn?: AnyPgColumn;
 }
+/**
+ * What a filter field turns out to name.
+ *
+ * A field naming a column compiles to a comparison on it. A field naming a
+ * relation that owns no column here compiles to a whole `EXISTS` condition
+ * instead, so there is no column to hand back — which is why resolution
+ * answers with a discriminated result rather than a column. The caller cannot
+ * tell the two apart from the field name, and the difference is not cosmetic:
+ * one is `column <op> value`, the other is a correlated subquery.
+ */
+type FilterTarget = {
+    kind: "column";
+    column: AnyPgColumn;
+} | {
+    /** A path *inside* a json/jsonb column — `metadata->>country`. */
+    kind: "json";
+    column: AnyPgColumn;
+    /** The keys to walk, outermost first. Always at least one. */
+    path: string[];
+} | {
+    kind: "relation";
+    relation: ResolvedForeignKeyOnTarget | ResolvedManyToMany;
+    /** Bound here so the compile step cannot be reached without them. */
+    registry: PostgresCollectionRegistry;
+    sourceIdColumn: AnyPgColumn;
+} | {
+    /**
+     * A *column of the related row* — `applications.status`. Same `EXISTS`
+     * as `relation`, with the predicate moved off the target's id and onto
+     * one of its columns.
+     */
+    kind: "relation-field";
+    /**
+     * `via` is not among them: it is refused at resolution, and leaving it
+     * in the type would let a later edit reach the compile step with a
+     * relation there is no correlation for.
+     */
+    relation: ResolvedBelongsTo | ResolvedForeignKeyOnTarget | ResolvedManyToMany;
+    registry: PostgresCollectionRegistry;
+    /** The column on *this* table the subquery correlates back to. */
+    sourceIdColumn: AnyPgColumn;
+    /** The table the predicate is asked of, already resolved. */
+    targetTable: PgTable<any>;
+    /** The column on {@link targetTable} the predicate compares. */
+    targetColumn: AnyPgColumn;
+};
 /** Drizzle dynamic query builder — accepts innerJoin + where chaining */
 export interface DrizzleDynamicQuery {
     innerJoin(table: PgTable<any>, condition: SQL): this;
@@ -166,6 +212,23 @@ export declare class DrizzleConditionBuilder {
      * rather than a half-built condition.
      */
     private static resolveFilterTarget;
+    /**
+     * `applications.status` — the relation, and the column of the target it
+     * addresses.
+     *
+     * `undefined` when the first segment names no relation: the field simply is
+     * not a relation path, and resolution carries on to the guesses and then to
+     * the unknown-field answer, which is where a typo belongs. A segment that
+     * *does* name a relation is a different matter — the author plainly meant
+     * this shape — so everything after that point throws rather than returning,
+     * naming what went wrong. Falling through would report "unknown filter
+     * field 'applications.status'" and list the columns of the wrong table.
+     *
+     * `via` is refused for the reason it is absent from
+     * `filterableRelationKinds`: its join path is authored source → target with
+     * no stated inverse, so there is nothing to correlate a subquery back to.
+     */
+    private static resolveRelationFieldTarget;
     /**
      * Build filter conditions from FilterValues
      */
@@ -278,6 +341,109 @@ export declare class DrizzleConditionBuilder {
      * a relation are exactly the six below.
      */
     private static buildRelationFilterPredicate;
+    /**
+     * A filter on a *column of the related row* — `applications.status`.
+     *
+     * The same `EXISTS` {@link buildRelationFilterCondition} builds, with the
+     * predicate moved off the target's id and onto one of its columns:
+     *
+     *     EXISTS (SELECT 1 FROM talent_applications AS t
+     *             WHERE t.talent_id = talents.id
+     *               AND t.status IN ('applied', 'reviewing', 'interview'))
+     *
+     * which is the shape every "who is waiting" queue is written in. Without
+     * it the only way to ask is to fetch every row and filter in the browser,
+     * and a filter the client applies after paging is not a filter — the page
+     * was already chosen without it.
+     *
+     * A many-to-many needs one more table than the id filter does. That one
+     * stops at the junction, because the junction already holds the value it
+     * compares; a column of the target is a table further out, so the subquery
+     * joins the target to the junction and correlates from the junction. The
+     * join is inside `EXISTS`, so it cannot multiply the outer rows the way a
+     * top-level join through a junction would.
+     *
+     * `belongsTo` is included even though its foreign key is a column here:
+     * `author.name` is a column of another table either way, and refusing the
+     * one relation kind that reads most naturally would be a rule about
+     * implementation rather than about meaning.
+     *
+     * Under RLS the subquery runs as the reader, so it sees the target rows
+     * that reader's policies allow and no others. On the positive direction
+     * that is exactly right. On the negative — `!=`, `not-in`, and any
+     * `NOT EXISTS` — "no related row satisfies this" and "no related row this
+     * reader can see satisfies this" are the same sentence, so a target table
+     * with row-level security and no `SELECT` policy for `rebase_user` makes
+     * every row look unmatched and the negative filter over-reports. Nothing is
+     * leaked: the outer table's own policies still decide which rows exist. The
+     * cause is a missing policy on the target rather than anything here, and it
+     * is the same caveat the id-filter path carries.
+     */
+    static buildRelationFieldCondition(target: Extract<FilterTarget, {
+        kind: "relation-field";
+    }>, op: WhereFilterOp, value: unknown, field: string, collectionPath: string): SQL;
+    /**
+     * The inner predicate of a relation *column* filter, and whether the
+     * `EXISTS` wrapping it is negated.
+     *
+     * The negation rule is the one {@link buildRelationFilterPredicate} states
+     * and holds for exactly the same reason, one column over. A negative
+     * operator is `NOT EXISTS` of the **positive** predicate, never `EXISTS` of
+     * a negated one: `EXISTS (… AND status != 'hired')` asks "does some
+     * application differ from hired", which is true of nearly every candidate
+     * with more than one application and answers nothing anybody asked.
+     * `NOT EXISTS (… AND status = 'hired')` asks "is there no hired
+     * application", which is what unticking a value means — and it makes `==`
+     * and `!=` partition the rows, the way a filter implies they do.
+     *
+     * `is-null` and `is-not-null` are the exception, and deliberately not a
+     * complementary pair here. On a column they compile to `EXISTS (… AND col
+     * IS NULL)` and `EXISTS (… AND col IS NOT NULL)` — "has a related row whose
+     * column is unset" and "has one where it is set" — which is the plain
+     * reading of `applications.status is-not-null` and the useful one. They are
+     * both true of a candidate with two applications, one of each. Making
+     * `is-not-null` the negation instead would make it "no application has an
+     * unset status", which is true of a candidate with no applications at all
+     * and so answers a queue with the very rows the queue exists to exclude.
+     *
+     * Unlike the id path, every operator is available: the compared value is an
+     * ordinary column, so `>=` on a date and `ilike` on a name mean here what
+     * they mean anywhere else. Only an operator that does not exist is refused,
+     * and it throws rather than returning `null` — a dropped condition widens
+     * the read, which is the whole reason this file fails closed.
+     */
+    private static buildRelationColumnPredicate;
+    /**
+     * An aggregate over the rows a relation reaches, as a scalar expression —
+     * what `orderBy: [{ relation: "applications", field: "created_at", agg:
+     * "min" }, "asc"]` compiles to.
+     *
+     *     (SELECT min(t.created_at) FROM talent_applications AS t
+     *      WHERE t.talent_id = talents.id)
+     *
+     * A correlated scalar subquery rather than a `LEFT JOIN LATERAL`: the join
+     * would have to be threaded into a query the relational query builder
+     * assembles, while a scalar expression drops straight into `ORDER BY` and
+     * into the keyset comparison behind cursor paging — which has to be the
+     * *same* expression, or paging and ordering disagree and rows are skipped.
+     *
+     * `correlateTo` is what the subquery is pinned against. Left out, it is the
+     * outer row's key column and the expression is correlated in the ordinary
+     * way. Given a literal — the cursor row's id — the subquery stops being
+     * correlated at all, so Postgres evaluates it once for the whole statement
+     * rather than per row. That is how a cursor pages over an aggregate it has
+     * no stored value for: the value is recomputed from the id it does have.
+     *
+     * Over zero related rows `count` is 0 and every other function is NULL,
+     * which is what puts "nobody waiting" at a defined end of the order rather
+     * than wherever a missing value would land. See `buildOrderExpressions` for
+     * where that end is pinned.
+     *
+     * Under RLS the subquery runs as the reader, so a related row the reader
+     * cannot see does not contribute — an aggregate is over the rows that
+     * reader can see, which is the only total it could honestly report.
+     */
+    static buildRelationAggregateExpression(spec: RelationAggregateSort, table: PgTable<any>, collection: CollectionConfig, registry: PostgresCollectionRegistry, sourceIdColumn: AnyPgColumn, collectionPath: string, correlateTo?: unknown): SQL;
     /** The column a table's rows are keyed by: its primary key, else `id`. */
     private static primaryKeyColumn;
     /**
@@ -491,3 +657,4 @@ export declare class DrizzleConditionBuilder {
  * This allows code to use PostgresConditionBuilder alongside future MongoConditionBuilder, etc.
  */
 export declare const PostgresConditionBuilder: typeof DrizzleConditionBuilder;
+export {};

package/dist/utils/pg-error-utils.d.ts

@@ -73,6 +73,33 @@ export declare function classifyConnectFailure(error: unknown): ConnectFailure;
  * error to the Studio SQL Editor user.
  */
 export declare function isRoleSwitchingPermissionError(error: unknown): boolean;
+/**
+ * Was this `42501` the *caller* being refused by a policy, rather than the
+ * server lacking a privilege?
+ *
+ * Both arrive as `insufficient_privilege`, and they are opposite kinds of
+ * problem. A row-level-security refusal is a working access-control system
+ * doing its job: the caller asked for something their policies do not permit,
+ * which is a 403 and nobody's bug. A missing `GRANT` is the deployment being
+ * wrong — the connection role cannot touch the table at all, no policy is
+ * involved, and nothing the caller changes about the request will help.
+ *
+ * Postgres distinguishes them in the message, so this does too:
+ *
+ *     new row violates row-level security policy for table "notes"  → the caller
+ *     permission denied for table notes                             → the server
+ *
+ * Only writes reach this. A read that RLS excludes is not an error — the rows
+ * are filtered and the caller gets an empty page — so the erroring case is
+ * specifically an `INSERT`/`UPDATE` whose row fails a policy's `WITH CHECK`.
+ *
+ * Matched on the message because that is the only thing carrying the
+ * distinction; the SQLSTATE is identical either way. Narrow by design: anything
+ * not naming row-level security stays the server's problem, since reporting a
+ * genuine privilege misconfiguration as "forbidden" would send an operator
+ * hunting for a policy bug that does not exist.
+ */
+export declare function isRowLevelSecurityDenial(error: unknown): boolean;
 /**
  * Translate a raw PostgreSQL error into a user-friendly message.
  *

package/dist/{websocket-D2jXv0Ds.js → websocket-BVgDVO-V.js}

@@ -3,7 +3,7 @@ import process from "process";
 __createRequire(import.meta.url);
 import { c as __exportAll } from "./connection-BuZ97wsr.js";
 import { n as resolveClientListLimit, r as ANONYMOUS_USER_ID, t as ListLimitError } from "./data_driver-ULAyJEi9.js";
-import "./src-DCdn3Val.js";
+import "./src-BBFsDaeA.js";
 import { ApiError, assertWriteRequestValid, extractUserFromToken, logger, resolveRequireAuth, safeCompare } from "@rebasepro/server";
 import { WebSocketServer } from "ws";
 import { inspect } from "util";
@@ -611,4 +611,4 @@ function createPostgresWebSocket(server, realtimeService, driver, authConfig, au
 //#endregion
 export { websocket_exports as n, createPostgresWebSocket as t };
 
-//# sourceMappingURL=websocket-D2jXv0Ds.js.map
+//# sourceMappingURL=websocket-BVgDVO-V.js.map