chore(electric): Reject tables that have columns with DEFAULT expressions

[alco]

Fixes VAX-1100.

• Add tests
• Update the type-checking function to use %I
• Create a follow-up issue in Linear.

[linear]

VAX-1100 Electrifying a table with `DEFAULT gen_random_uuid()` yields a broken default "gen_random_uuid" string in SQLite

Reported in Discord: https://discord.com/channels/933657521581858818/1079688869852753981/1156299210400989194

TLDR: The table below electrifies without problems:

CREATE TABLE "public"."DataTable" (
    "id" uuid NOT NULL DEFAULT gen_random_uuid(),
    "name" text NOT NULL,
    "created_at" float8 NOT NULL,
    "electric_user_id" text NOT NULL,
    PRIMARY KEY ("id")
);

However, the default values gets translated to DEFAULT 'gen_random_uuid' in the corresponding SQLite schema. When a client write omits the id field, it gets the default value gen_random_uuid which then fails server-side validation.

Proposed fix: check for DEFAULT clauses in the electrify() function and

• reject such tables
• or erase the DEFAULT part when translating the Postgres schema to SQLite

Postgres has a vastly larger set of built-in functions and expressions compared to SQLite. We cannot possibly allow electrification of tables with arbitrary DEFAULT expressions.

[gorbak25]

@alco I think this PR might be too strict. I think a better approach would be to remove default expressions from sqlite and keep them in progress. The prisma client can ensure those fields with default expressions are not optional on the client side.

[alco]

@gorbak25 I agree that it's strict. But it's aimed at fixing a very particular problem.

Whether we skip DEFAULT clauses from the client schema or add support for limited expressions there, both require some planning and development time. In the time window between now and when we release a version with a proper fix, people who electrify their tables containing DEFAULT clauses will get broken server sync when trying out Electric.

We would prefer to make it known upfront that a given table cannot be electrified and relax this limitation later.

[magnetised]

Looks good apart from function->procedure switch

[barbalex]

I just stumbled on to this, getting an error when trying to electrify a table.
It seems that this is not documented anywhere nor whether this will be possible in the future.

[thruflo]

Yes, this should be documented. I've raised an issue [VAX-1405].

It will be relaxed in future. I don't have visibility on timeframe though.