feat: implement REMOVE TABLE operation support

[MH4GF]

#2107 is merged, remove the WIP.

Issue

• resolve: Implement support for REMOVE TABLE operations in the database schema operation system

Why is this change needed?

This change adds support for the remove operation on tables, allowing users to generate DROP TABLE DDL statements through the operation system. This completes the table operation support alongside the existing add operation.

What would you like reviewers to focus on?

• Schema definition for RemoveTableOperation in table.ts
• DDL generation logic in generateRemoveTableStatement function
• Integration with the operation deparser
• Test coverage for the new functionality
• Consistency with existing operation patterns

Testing Verification

• All existing tests continue to pass
• New comprehensive tests added for remove table operations
• Verified DDL generation produces correct DROP TABLE {tableName}; statements
• Ran quality checks: pnpm fmt, pnpm lint, and pnpm test all pass

What was done

🤖 Generated by PR Agent at 2832784

• Add support for REMOVE TABLE operations with DROP TABLE DDL generation
• Implement RemoveTableOperation schema and type guard validation
• Update operation deparser to handle table removal operations
• Add comprehensive test coverage for remove table functionality

Detailed Changes

	Relevant files
Enhancement	table.ts Add RemoveTableOperation schema and type guard                      frontend/packages/db-structure/src/operation/schema/table.ts • Add RemoveTableOperation schema with 'remove' op and table path validation • Create isRemoveTableOperation type guard function • Export RemoveTableOperation type and update tableOperations array +21/-1    utils.ts Add DROP TABLE statement generation utility                            frontend/packages/db-structure/src/deparser/postgresql/utils.ts • Add generateRemoveTableStatement function that creates DROP TABLE DDL • Simple implementation returning formatted DROP TABLE statement +7/-0      operationDeparser.ts Integrate remove table operation in deparser                          frontend/packages/db-structure/src/deparser/postgresql/operationDeparser.ts • Import RemoveTableOperation type and isRemoveTableOperation guard • Add generateRemoveTableFromOperation function with path validation • Integrate remove table operation handling in main deparser function +28/-2
Tests	operationDeparser.test.ts Update test to verify DROP TABLE generation                            frontend/packages/db-structure/src/deparser/postgresql/operationDeparser.test.ts • Update test from expecting error to verifying DROP TABLE generation • Change test expectations to validate successful DDL output +5/-4

Additional Notes

This implementation follows the established operation support pattern and maintains consistency with existing table operations. The remove operation only requires a path (no value) since it's a deletion operation.

🤖 Generated with Claude Code

---

Need help?

Type /help how to ... in the comments thread for any questions about Qodo Merge usage.

Check out the documentation for more information.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 2832784

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
liam-app	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jun 20, 2025 7:31am
liam-erd-sample	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jun 20, 2025 7:31am
liam-storybook	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jun 20, 2025 7:31am

1 Skipped Deployment

Name	Status	Preview	Comments	Updated (UTC)
liam-docs	⬜️ Ignored (Inspect)			Jun 20, 2025 7:31am

[qodo-merge-for-open-source]

PR Reviewer Guide 🔍

(Review updated until commit 2832784)

Here are some key observations to aid the review process:

⏱️ Estimated effort to review: 2 🔵🔵⚪⚪⚪

🧪 PR contains tests

🔒 Security concerns SQL injection: The generateRemoveTableStatement function at line 122 directly concatenates the tableName parameter into the SQL statement without proper escaping or validation. If the table name contains SQL metacharacters or malicious code, it could lead to SQL injection vulnerabilities. Consider using proper SQL identifier escaping or parameterized queries.

⚡ Recommended focus areas for review SQL Injection The generateRemoveTableStatement function directly concatenates the table name without proper escaping or validation, which could lead to SQL injection if the table name contains malicious SQL code. export function generateRemoveTableStatement(tableName: string): string { return `DROP TABLE ${tableName};` }

[qodo-merge-for-open-source]

PR Code Suggestions ✨

Latest suggestions up to 2832784
Explore these optional code suggestions:

Category	Suggestion	Impact
General	Add SQL identifier escaping The DROP TABLE statement should include proper SQL identifier escaping to handle table names with special characters or reserved keywords. Consider adding IF EXISTS clause for safer operations. frontend/packages/db-structure/src/deparser/postgresql/utils.ts [121-123] export function generateRemoveTableStatement(tableName: string): string { - return `DROP TABLE ${tableName};` + return `DROP TABLE IF EXISTS "${tableName}";` } Apply / Chat Suggestion importance[1-10]: 8 __ Why: The suggestion correctly points out the lack of SQL identifier escaping for tableName. This is important for handling table names that are reserved keywords or contain special characters. Additionally, adding IF EXISTS makes the generated SQL statement more robust and prevents errors when trying to drop a non-existent table.	Medium
Learned best practice	Add input parameter validation Add validation to check if the tableName parameter is properly defined and not empty before generating the DROP TABLE statement. This prevents generating invalid SQL with empty or undefined table names. frontend/packages/db-structure/src/deparser/postgresql/utils.ts [121-123] export function generateRemoveTableStatement(tableName: string): string { + if (!tableName || tableName.trim() === '') { + throw new Error('Invalid table name: expected non-empty string') + } return `DROP TABLE ${tableName};` } Apply / Chat Suggestion importance[1-10]: 6 __ Why: Relevant best practice - Add explicit validation for input parameters at the beginning of functions to ensure they are properly defined and in the expected format before processing. This prevents runtime errors from null, undefined, or malformed data.	Low
More

---

Previous suggestions

Suggestions up to commit 2832784

Category	Suggestion	Impact
Security	Add SQL identifier quoting The DROP TABLE statement should include proper SQL identifier quoting to handle table names with special characters or reserved keywords. This prevents SQL injection and syntax errors when table names contain spaces, special characters, or are PostgreSQL reserved words. frontend/packages/db-structure/src/deparser/postgresql/utils.ts [121-123] export function generateRemoveTableStatement(tableName: string): string { - return `DROP TABLE ${tableName};` + return `DROP TABLE "${tableName}";` } Suggestion importance[1-10]: 8 __ Why: The suggestion correctly identifies a potential issue where table names with special characters or reserved keywords could cause SQL syntax errors. Quoting the table name is a standard security and robustness practice that prevents such errors.	Medium
General	Add CASCADE/RESTRICT option support Consider adding CASCADE or RESTRICT option to the DROP TABLE statement to make the behavior explicit. Without specifying this, the operation may fail if there are dependent objects like foreign key constraints. frontend/packages/db-structure/src/deparser/postgresql/utils.ts [121-123] -export function generateRemoveTableStatement(tableName: string): string { - return `DROP TABLE ${tableName};` +export function generateRemoveTableStatement(tableName: string, cascade: boolean = false): string { + const cascadeClause = cascade ? ' CASCADE' : ' RESTRICT' + return `DROP TABLE "${tableName}"${cascadeClause};` } Suggestion importance[1-10]: 6 __ Why: This is a valuable feature enhancement. Adding support for CASCADE would make the DROP TABLE functionality more robust by handling dependencies automatically. However, this is an extension of functionality rather than a fix for a bug in the current PR, and would require changes beyond the suggested code snippet, such as updating the RemoveTableOperation schema.	Low
Learned best practice	Add input parameter validation The function should validate that the tableName parameter is not null, undefined, or empty before using it in the SQL statement. This prevents generating invalid SQL with empty table names. frontend/packages/db-structure/src/deparser/postgresql/utils.ts [121-123] export function generateRemoveTableStatement(tableName: string): string { + if (!tableName || tableName.trim() === '') { + throw new Error('Invalid table name: expected non-empty string'); + } return `DROP TABLE ${tableName};` } Suggestion importance[1-10]: 6 __ Why: Relevant best practice - Add explicit validation for input parameters at the beginning of functions to ensure they are properly defined and in the expected format before processing. This prevents runtime errors from null, undefined, or malformed data.	Low

[hoshinotsuyoshi]

LGTM!