Repository navigation
[Decision] 会说 Postgres 方言的另外两种数据库（Redshift、CockroachDB），平台要不要当 Postgres 来建表?（#11550 的宽半边） #11756
Description
Activity
Measured while landing the narrow half (#11550 → PR #11783). Two more clients fall inside this decision's scope, so recording them here rather than filing a near-duplicate card.
The full picture, read from the pinned knex (3.3.0)
lib/constants.jsplus a live client construction per spelling:knex client knex dialectknex driverNamerecognised for emission today postgres/pg/postgresqlpostgresqlpgyes (after PR #11783) cockroachdbpostgresqlcockroachdbno redshiftredshiftpg-redshiftno pgnativepostgresqlpgnativeno mysql/mysql2mysqlmysql/mysql2yes mariadbmariadbmariadbno Two things this table adds to the question as framed:
-
pgnativeis the easy end of this decision and is currently lumped in with the hard end. knex resolves it todialect === 'postgresql'— it is the Postgres dialect, compiled by the same code, differing only in which npm binding carries the bytes. If Redshift is the "diverges on DDL, needs a real ruling" case,pgnativeis close to its opposite. Worth answering separately rather than inheriting Redshift's answer by silence. It is also absent fromPOSTGRES_WIRE_CLIENTS, so today it gets neither emission nor the driver-sql: every Field.date read from PostgreSQL is one day early when the process TZ is east of UTC — toDateOnly() reads UTC components off a local-midnight Date #11389 calendar-day parser pin. -
cockroachdbalready resolves to knex'spostgresqldialect too — so for cockroachdb the question is not "does knex think this is Postgres" (it does) but "does this platform want to claim its DDL is correct there". Redshift is the only one of the four where knex itself says a different dialect.
mariadbis the same shape one family over: a separate knex dialect, not an alias ofmysql, and not recognised today.PR #11783 pins the current answer for
redshift/cockroachdb/mariadbexplicitly (they keep wire recognition, gain no emission identity) insql-driver-11550-dialect-client-spellings.test.ts, under a docblock naming this card. Those cases are meant to be rewritten when this is decided — that is how the decision lands deliberately instead of arriving as a side effect of a refactor.
Generated by Claude Code
-
Maintainer ruling — C, plus
pgnativejoins the Postgres familySource: maintainer, 2026-08-25, live PM chat (decision-inbox batch 3 review, session
session_01KWRU3s15AJz7PGW7a7wdCh), verbatim: 「同意」 — accepting the batch's presented recommendation for this card: 「C，但 pgnative 归入 Postgres 家族」.redshift/cockroachdb: wire recognition stays (connection/parsing per driver-sql: every Field.date read from PostgreSQL is one day early when the process TZ is east of UTC — toDateOnly() reads UTC components off a local-midnight Date #11389, deliberate); no emission identity. A configuration that reaches the DDL-emission path gets an immediate named refusal with guidance — never a silently mis-built table. The boundary sits where the platform has actually verified behaviour (wire yes, emission no), stated in the open.pgnative: recognised into the Postgres family for emission (knex resolves it to the samepostgresqldialect — it was the easy end lumped in with the hard end) and added to the wire table, from which it is also absent today.mariadb: explicitly out of this ruling's scope; stays unrecognised.- The deliberately-pinned cases in
sql-driver-11550-dialect-client-spellings.test.ts(PR fix(driver-sql): recognise knex's canonicalpostgres/sqliteclient spellings in the dialect getters #11783, docblock naming this card) are rewritten by the implementation on purpose — the ruling lands as an explicit rewrite, never as refactor fallout.
Recorded reopening condition (the analysis's stated blind spot, business-pull axis): no customer is known on either database; evidence of a real Redshift/CockroachDB customer reopens this toward A, starting with a measured DDL-difference boundary and the two databases judged separately.
Implementation card filed per the confirmed checklist (linked in the follow-up). Closing completed;
needs-user-decisionoff in the same write.
Generated by Claude Code
由
domain:engine执行席落卡（sessionsession_01VK8rFDtg8eREaxBGX99Csn）。这是 #11550 被切下来的宽半边。 窄半边（认 knex 自己的规范拼写postgres/sqlite）已派发 —— 那半边是「我们本来就支持这个方言，只是漏认了一种写法」，不需要谁裁。这半边不一样：它决定平台对外声称支持哪些数据库，属于扩大公开面，恒交维护者。一句话问题
有两种数据库（Redshift、CockroachDB）会说 Postgres 的话 —— 连上去、发查询、读结果都通。问题是：客户拿它们当数据库时，平台要不要照 Postgres 的方式替他们建表。它们在「怎么存、怎么建表」上和真 Postgres 是有差别的，Redshift 尤其明显。
前提（带 re-check 命令）
git grep -n "isPostgres\|DIALECT_CONNECT_TIMEOUT\|POSTGRES_WIRE_CLIENTS" origin/main -- packages/drivers/driver-sql/src/sql-driver.ts（2026-08-24 实测：身份 getter 只认
pg/postgresql；连接超时表另外还含cockroachdb；wire 表另外还含redshift）client: 'postgres'silently loses every dialect-specific behaviour #11550 的 PR 是否已合。三条路，和客户能感觉到的代价
业务含义直译：A =「我们说支持 Redshift」；B =「我们没说，你自己看着办」；C =「我们说清楚：连得上，但建表这块我们不替你负责」。
os-decision-facets推荐：C（认 wire、不认 emission，并把边界写明并给出响亮拒绝），回退 B。 四轴里没有一条支持 A，但其中一轴（实际业务拉动）我是空的 —— 如果你知道有客户在用 Redshift，这个推荐要重算。
裁后我会怎么执行（你不用管）
domain:engine队列：把三张表收敛成「一个发射身份源 + 其它表在其上扩展」，并给这两个 client 一句点名的拒绝（含建议）。client: 'postgres'silently loses every dialect-specific behaviour #11550 上记明「宽半边不做」及理由，不再立卡。低摩擦裁决格式：回一个字母即可；「C，但 X」我按 C 落地并把 X 记进卡里；不回就留在箱里，⛔ 不会有人替你裁。
相关
client: 'postgres'silently loses every dialect-specific behaviour #11550 —— 母卡，窄半边已派发（认postgres/sqlite两种规范拼写）redshift放进POSTGRES_WIRE_CLIENTS的那张卡（wire 层，不是发射层）