feat: add noTransaction parameter to tables.create() and columns.crea…

[7ttp]

Summary

Adds optional noTransaction parameter to tables.create() and columns.create() that skips BEGIN...COMMIT wrappers when set to true, enabling atomic multi-operation transactions.

Problem

Each create() call wraps SQL in its own transaction.

Solution

Added noTransaction parameter (defaults to false for BC) that conditionally wraps SQL.

Related

• Closes Table Editor allows partial creation and remains open on SQL error supabase#42089
• Follows @djhi's suggestion regarding the above
• adds up to feat(studio): wrap table creation in single atomic transaction supabase#43352

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Central YAML (base), Organization UI (inherited)

Review profile: CHILL

Plan: Pro

Run ID: 0401ceae-b11a-4299-99e4-e0eb1abe95ac

📥 Commits

Reviewing files that changed from the base of the PR and between 7fe7a09 and ef41be8.

📒 Files selected for processing (1)

• src/lib/PostgresMetaColumns.ts

---

📝 Walkthrough

Summary by CodeRabbit

• New Features
  • Added an optional non-transactional mode for creating database tables and columns, allowing create and comment operations to run without being wrapped in a transaction.

Walkthrough

This PR adds a noTransaction boolean parameter to the PostgresMetaColumns.create() and PostgresMetaTables.create() methods, with a default value of false. The parameter controls whether the generated SQL statements are wrapped in a transaction. When noTransaction is true, the SQL executes without BEGIN/COMMIT. When false (default), operations remain wrapped in a transaction as before. The corresponding type definitions in PostgresColumnCreate and PostgresTableCreate are updated to include this optional field.

Sequence Diagram(s)

(omitted)

Assessment against linked issues

Objective	Addressed	Explanation
Make table creation atomic so that if a column creation fails, the entire table creation is rolled back [#42089]	❓	The PR exposes a noTransaction flag but does not change default transactional behavior; it's unclear whether callers will use this to ensure table+column creation occur in a single transaction.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[7ttp]

@avallete @mandarini

[avallete]

I’m leaning against approving this.

I’d rather keep postgres-meta endpoints atomic by default and avoid adding app-specific transaction control to these helpers. For cases like this, Studio should build and own the full SQL/transaction it needs and use the lower-level query path instead of extending the tables.create() / columns.create() API surface with noTransaction.

[djhi]

Closed in favor of #43909. Thanks!