bigserial (DBML) vs bigint #18

New Issue

2026-08-18T10:31:54Z

warkanum commented

2026-08-18 10:31:54 +00:00

The relspec merge approach is blocked by a real limitation: it treats every bigserial (DBML) vs bigint (what Postgres reports back for an existing serial column) as a genuine type conflict, and refuses to proceed on any conflict. Since this schema has ~250 serial PKs, that trips on virtually every table — not just 1 conflict, it's fundamentally incompatible with this schema as an apply mechanis

warkanum added the Kind/Bug label 2026-08-18 10:32:01 +00:00

warkanum commented

2026-08-18 11:36:45 +00:00

same class of bug, different flavor: relspec's convert --to pgsql generator wraps bare keyword defaults like CURRENT_DATE in string quotes (DEFAULT 'CURRENT_DATE') instead of emitting them as an unquoted expression, even though the source DBML correctly uses backtick-expression syntax (default: CURRENT_DATE, db/healthwizzard.dbml:827). Function-call defaults like now()/gen_random_uuid() render fine — only bare keywords like this trip it. Patched all 3 occurrences in db/migration/migration.sql (CREATE TABLE, ALTER TABLE ADD COLUMN, and a SET DEFAULT block).

same class of bug, different flavor: relspec's convert --to pgsql generator wraps bare keyword defaults like CURRENT_DATE in string quotes (DEFAULT 'CURRENT_DATE') instead of emitting them as an unquoted expression, even though the source DBML correctly uses backtick-expression syntax (default: `CURRENT_DATE`, db/healthwizzard.dbml:827). Function-call defaults like now()/gen_random_uuid() render fine — only bare keywords like this trip it. Patched all 3 occurrences in db/migration/migration.sql (CREATE TABLE, ALTER TABLE ADD COLUMN, and a SET DEFAULT block).

warkanum commented

2026-08-18 11:51:52 +00:00

Fixed

warkanum closed this issue

2026-08-18 11:51:52 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: wdevs/relspecgo#18