feat: postgres custom schema

[ymc9]

Summary by CodeRabbit

• New Features

  • Support for PostgreSQL schemas including per-model schema annotation and defaultSchema propagation.

• Improvements

  • Name-mapping and query generation now respect PostgreSQL schemas.
  • Provider objects and schema handling enriched to include an optional defaultSchema.
  • Validation tightened to enforce schema presence and provider-specific constraints.

• Tests

  • Added end-to-end tests covering multi-schema scenarios, validation errors, and provider restrictions.

• Documentation

  • Improved schema attribute documentation comment for PostgreSQL.

[coderabbitai]

Note

Other AI code review bot(s) detected

CodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review.

Walkthrough

Adds PostgreSQL custom schema support: activates @@Schema docs, validates schema names and datasource schema fields, propagates schema names through ORM name mapping and executor initialization, extends schema/provider types and generators, centralizes test schema placeholder handling, and adds end-to-end PostgreSQL schema tests.

Changes

Cohort / File(s)	Summary
Schema documentation packages/language/res/stdlib.zmodel	Re-enabled and reworded the documentation comment for the Prisma @@schema attribute, changing the param tag to @param name: and making the description Postgres-specific.
Validation layer packages/language/src/validators/attribute-application-validator.ts, packages/language/src/validators/datasource-validator.ts	Added _checkSchema() checker to ensure @@schema literal names exist in the datasource's schemas; datasource validator now enforces provider is a string literal, restricts defaultSchema and schemas to PostgreSQL, and validates schemas is an array of string literals.
Schema types packages/schema/src/schema.ts	Added optional defaultSchema?: string to the DataSourceProvider interface.
SDK schema generator packages/sdk/src/ts-schema-generator.ts	Made provider extraction return a string literal, added getDataSourceDefaultSchema() to read/validate defaultSchema, and include defaultSchema in generated provider objects when present.
ORM name mapping & executor packages/orm/src/client/executor/name-mapper.ts, packages/orm/src/client/executor/zenstack-query-executor.ts	Introduced createTableNode() and getTableSchema() to attach optional schemas to table nodes (Postgres-only); enabled name mapping initialization for Postgres when schemas are used.
Test tooling packages/testtools/src/schema.ts, packages/testtools/src/client.ts	Added replacePlaceholders() helper for schema text substitution; updated generateTsSchema() callsites and preserved existing provider fields when merging generated provider objects.
E2E tests tests/e2e/orm/client-api/pg-custom-schema.test.ts	Added end-to-end tests covering public/default schema behavior, custom default schemas, multiple schemas and per-model @@schema, provider rejection for non-Postgres, and undefined-schema errors.

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~60 minutes

• Pay attention to: validation logic in attribute-application-validator.ts and datasource-validator.ts; schema propagation in name-mapper.ts and zenstack-query-executor.ts; correct extraction/validation of defaultSchema in ts-schema-generator.ts; and new E2E test assumptions about Postgres setup.

Possibly related PRs

• fix: add a few missing zmodel validation checks #101 — Adds a similar @check validation method to AttributeApplicationValidator; likely overlaps in attribute validation logic.
• merge dev to main #66 — Modifies generateTsSchema() / test schema generation; related to placeholder handling and test tooling changes.

Poem

🐰 I nibble through docs and validators bright,

hopping schemas by day and by night,
I stitch tables to burrows in Postgres delight,
tests dance and pass under moonlight,
a tidy warren, all mapped just right.

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'feat: postgres custom schema' directly and clearly summarizes the main objective of the PR, which is to add PostgreSQL custom schema support across the codebase.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch feat/pg-multi-schema

---

📜 Recent review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between ea7145b and 8edc5a3.

📒 Files selected for processing (1)

• packages/orm/src/client/executor/zenstack-query-executor.ts (1 hunks)

🚧 Files skipped from review as they are similar to previous changes (1)

• packages/orm/src/client/executor/zenstack-query-executor.ts

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)

• GitHub Check: build-test (20.x, postgresql)
• GitHub Check: build-test (20.x, sqlite)
• GitHub Check: claude-review

---

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.}

[claude]

Claude finished @ymc9's task —— View job

---

PostgreSQL Custom Schema Support - PR Review

I've completed a comprehensive review of this PR, which adds PostgreSQL custom schema support to ZenStack. Here's my detailed analysis:

Summary of Changes

This PR introduces comprehensive PostgreSQL custom schema support through:

1. Language Support: Added @@schema attribute and defaultSchema/schemas datasource fields
2. Validation: Proper validation for PostgreSQL-specific schema features
3. ORM Integration: Schema-aware query generation and table name mapping
4. Code Generation: Schema information propagated to TypeScript schema output
5. Comprehensive Testing: E2E tests covering various schema scenarios

✅ Strengths

1. Comprehensive Implementation

• Proper Langium Integration: Clean AST updates in stdlib.zmodel with correct attribute definitions
• Type Safety: Strong typing with schema information in the DataSourceProvider type
• Database Abstraction: Schema handling isolated to PostgreSQL provider only

2. Robust Validation Logic (packages/language/src/validators/)

• Provider Validation: Schema features correctly restricted to PostgreSQL only
• Schema Reference Validation: Validates @@schema references against defined schemas in datasource
• Error Messages: Clear, actionable error messages for schema misuse

3. Excellent ORM Implementation (packages/orm/)

• Performance Optimized: Name mapper only instantiated when needed (schemas or mapped names exist)
• Query Correctness: Proper handling of schema-qualified table names using Kysely's TableNode.createWithSchema()
• SQL Generation: Clean schema qualification in generated SQL ("schema"."table")

4. Thorough Test Coverage

The test suite is comprehensive and well-designed:

• Default Behavior: Verifies 'public' schema is used by default
• Custom Schema: Tests both ORM and QB queries with custom schemas
• Validation: Error cases for non-PostgreSQL providers and undefined schemas
• Real DB Integration: Uses usePrismaPush for realistic testing

⚠️ Areas for Improvement

1. Security Considerations

// name-mapper.ts:474-476
private createTableNode(tableName: string, schemaName: string | undefined) {
    return schemaName ? TableNode.createWithSchema(schemaName, tableName) : TableNode.create(tableName);
}

Recommendation: Consider SQL injection protection for schema/table names, especially if they come from user input. While Kysely likely handles this, explicit validation would be safer.

2. Error Handling Robustness

// ts-schema-generator.ts:643-656  
private getDataSourceDefaultSchema(model: Model) {
    // Uses invariant but could be more defensive
    invariant(
        isLiteralExpr(defaultSchemaExpr) && typeof defaultSchemaExpr.value === 'string',
        'Default schema must be a string literal',
    );
}

Recommendation: Add graceful fallback handling for malformed schemas instead of throwing invariants.

3. Performance Optimization

// zenstack-query-executor.ts:58-60
if (this.schemaHasCustomPostgresSchema(client.$schema) || this.schemaHasMappedNames(client.$schema)) {
    this.nameMapper = new QueryNameMapper(client.$schema);
}

Recommendation: Consider caching the name mapper instance per schema to avoid repeated instantiation.

4. Code Quality Improvements

Type Safety Enhancement:

// Current: Uses string comparisons
if (schema.provider.type !== 'postgresql') {
    return false;
}

// Suggested: Use enum/const for better type safety
enum DatabaseProvider {
    POSTGRESQL = 'postgresql',
    SQLITE = 'sqlite'
}

Documentation: Some complex logic in name-mapper.ts would benefit from inline documentation explaining the scoping rules and alias resolution.

🐛 Potential Issues

1. Case Sensitivity (Minor)

// pg-custom-schema.test.ts:143-148
if (sql.includes('"myschema"."foo"')) {
    fooQueriesVerified = true;
}

Test assumes lowercase schema names in SQL output. PostgreSQL identifiers are case-sensitive when quoted, so this could be brittle if schema casing changes.

2. Migration Considerations (Minor)

The PR doesn't address how existing databases without custom schemas migrate to using this feature. Consider documenting migration patterns.

📋 Code Quality Assessment

• Architecture: ✅ Excellent - Clean separation of concerns
• Error Handling: ✅ Good - Comprehensive validation with clear messages
• Performance: ✅ Good - Efficient implementation with conditional activation
• Testing: ✅ Excellent - Comprehensive coverage of all scenarios
• Documentation: ⚠️ Fair - Could use more inline documentation for complex logic
• Security: ⚠️ Good - No obvious vulnerabilities, but could be more defensive

🚀 Recommendations for Future Enhancements

1. Schema Migration Utilities: Helper functions for migrating between schema configurations
2. Query Optimization: Analyze if schema-qualified queries impact PostgreSQL query planning
3. Multi-tenant Support: Consider how this feature enables multi-tenant architectures
4. Monitoring Integration: Add metrics/logging for schema-qualified query performance

Final Verdict

This is a well-implemented, production-ready feature that adds significant value to ZenStack's PostgreSQL support. The implementation is thorough, properly tested, and follows good architectural patterns. The identified issues are minor and don't block the PR.

Recommended Action: ✅ Approve with minor suggestions

The PostgreSQL custom schema support is ready for production use and provides a solid foundation for advanced PostgreSQL deployment patterns.

---

Technical Quality Score: 8.5/10

• Implementation: 9/10
• Testing: 9/10
• Architecture: 9/10
• Documentation: 7/10
• Security: 8/10

---

[ymc9]

fixes #346

[coderabbitai]

Actionable comments posted: 2

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

packages/testtools/src/client.ts (1)

82-88: Preserve provider metadata for object schemas.

When callers pass a pre-built Schema, this branch now overwrites schema.provider with { type }, discarding new fields like defaultSchema. That breaks PostgreSQL schema tests using the object form.

Keep the existing provider fields:

         _schema = {
             ...schema,
             provider: {
-                type: provider,
+                ...schema.provider,
+                type: provider,
             },
         };

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between fd5db63 and ea7145b.

📒 Files selected for processing (10)

• packages/language/res/stdlib.zmodel (1 hunks)
• packages/language/src/validators/attribute-application-validator.ts (3 hunks)
• packages/language/src/validators/datasource-validator.ts (2 hunks)
• packages/orm/src/client/executor/name-mapper.ts (5 hunks)
• packages/orm/src/client/executor/zenstack-query-executor.ts (1 hunks)
• packages/schema/src/schema.ts (1 hunks)
• packages/sdk/src/ts-schema-generator.ts (2 hunks)
• packages/testtools/src/client.ts (2 hunks)
• packages/testtools/src/schema.ts (2 hunks)
• tests/e2e/orm/client-api/pg-custom-schema.test.ts (1 hunks)

🧰 Additional context used

🧠 Learnings (1)

📚 Learning: 2025-10-21T16:09:31.218Z

Learnt from: ymc9
Repo: zenstackhq/zenstack-v3 PR: 319
File: packages/runtime/src/client/executor/zenstack-query-executor.ts:63-72
Timestamp: 2025-10-21T16:09:31.218Z
Learning: In ZenStack, TypeDefs can be inherited by models. When a TypeDef contains fields with `map` attributes, those mapped field names need to be processed by the QueryNameMapper since they become part of the inheriting model's schema. Therefore, when checking if a schema has mapped names (e.g., in `schemaHasMappedNames`), both `schema.models` and `schema.typeDefs` must be inspected for `@map` and `map` attributes.

Applied to files:

• packages/orm/src/client/executor/zenstack-query-executor.ts
• packages/orm/src/client/executor/name-mapper.ts

🧬 Code graph analysis (6)

packages/sdk/src/ts-schema-generator.ts (2)

packages/common-helpers/src/tiny-invariant.ts (1)

• invariant (4-14)

packages/language/src/generated/ast.ts (4)

• isLiteralExpr (133-135)
• Model (559-563)
• Model (565-565)
• isDataSource (417-419)

tests/e2e/orm/client-api/pg-custom-schema.test.ts (1)

packages/testtools/src/client.ts (1)

• createTestClient (53-182)

packages/orm/src/client/executor/zenstack-query-executor.ts (1)

packages/schema/src/schema.ts (1)

• SchemaDef (11-19)

packages/language/src/validators/datasource-validator.ts (3)

packages/language/src/utils.ts (1)

• getStringLiteral (75-77)

packages/language/src/constants.ts (1)

• SUPPORTED_PROVIDERS (4-11)

packages/language/src/generated/ast.ts (2)

• isConfigArrayExpr (290-292)
• isLiteralExpr (133-135)

packages/testtools/src/client.ts (2)

packages/testtools/src/schema.ts (1)

• generateTsSchema (40-74)

tests/e2e/orm/schemas/basic/schema.ts (1)

• schema (9-284)

packages/language/src/validators/attribute-application-validator.ts (4)

packages/schema/src/schema.ts (1)

• AttributeApplication (40-43)

packages/language/src/utils.ts (1)

• getStringLiteral (75-77)

packages/common-helpers/src/tiny-invariant.ts (1)

• invariant (4-14)

packages/language/src/generated/ast.ts (4)

• isModel (567-569)
• isDataSource (417-419)
• isConfigArrayExpr (290-292)
• isLiteralExpr (133-135)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (4)

• GitHub Check: Agent
• GitHub Check: build-test (20.x, sqlite)
• GitHub Check: claude-review
• GitHub Check: build-test (20.x, postgresql)

🔇 Additional comments (12)

packages/testtools/src/schema.ts (1)

35-54: Helper centralizes placeholder handling cleanly.

Thanks for extracting the placeholder replacement into replacePlaceholders and reusing it in generateTsSchema; the schema setup logic is clearer and easier to reuse.

packages/schema/src/schema.ts (1)

6-9: Provider type is ready for default schemas.

Adding defaultSchema?: string on the provider surfaces the new capability to the rest of the stack without breaking existing callers. 👍

packages/language/res/stdlib.zmodel (1)

457-463: Docstring clarifies PostgreSQL-only usage.

Appreciate the explicit documentation of @@schema; it matches the new validation semantics.

packages/sdk/src/ts-schema-generator.ts (3)

237-255: LGTM! Clean implementation of defaultSchema support.

The conditional inclusion of defaultSchema in the provider object is handled correctly using the spread operator pattern. The implementation properly extracts the value and only includes it when present.

---

631-641: LGTM! Enhanced validation for provider field.

The stricter validation using invariant ensures the provider is always a string literal, which aligns with the validation rules in datasource-validator.ts. The change to return a string directly (rather than an object) simplifies the API and is consistent with how the value is used in createProviderObject.

---

643-656: LGTM! Consistent implementation following established patterns.

The new getDataSourceDefaultSchema method mirrors the structure of getDataSourceProvider, maintaining consistency in the codebase. The validation ensures defaultSchema is a string literal when present, and correctly returns undefined when the field is absent.

packages/language/src/validators/datasource-validator.ts (2)

26-39: LGTM! Enhanced provider validation with better error messages.

The validation now enforces that the provider is both a string literal and within the supported providers list. The error message helpfully lists all supported providers, improving the developer experience.

---

41-64: LGTM! Comprehensive validation for PostgreSQL-specific schema features.

The validation correctly enforces that defaultSchema and schemas fields are only allowed for PostgreSQL providers. The schemas field validation properly checks both the array structure and that all items are string literals.

tests/e2e/orm/client-api/pg-custom-schema.test.ts (4)

6-35: LGTM! Comprehensive test of default public schema behavior.

The test effectively verifies that ORM queries default to the public schema by inspecting the generated SQL. The flag-based verification pattern ensures all CRUD operations are covered.

---

70-112: LGTM! Good test of default schema behavior and error handling.

The test verifies both the error case (non-existent schema) and success case (valid schema). The error message check on Line 89 depends on PostgreSQL's error format, which is acceptable for E2E tests but could be fragile across PostgreSQL versions.

---

114-158: LGTM! Excellent test of multi-schema functionality.

This test comprehensively validates per-model schema annotations with multiple schemas defined in the datasource. The use of usePrismaPush: true is appropriate here to ensure the schemas are actually created in PostgreSQL before testing queries against them.

---

160-195: LGTM! Comprehensive validation error coverage.

These tests properly verify that the validation rules are enforced:

1. Schema features are rejected for non-PostgreSQL providers
2. Model schema annotations must reference schemas defined in the datasource

The error message assertions using toThrow with substrings are appropriate for validating that the right validation errors are raised.

[Copilot]

Pull Request Overview

This PR adds support for PostgreSQL custom schemas in ZenStack, allowing users to specify which database schema models should be created in and set default schemas at the datasource level.

Key changes:

• Added @@schema attribute for models and defaultSchema/schemas fields for datasources
• Implemented schema name mapping in query execution layer
• Added validation for schema-related fields to ensure they're only used with PostgreSQL

Reviewed Changes

Copilot reviewed 10 out of 10 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
tests/e2e/orm/client-api/pg-custom-schema.test.ts	Comprehensive test coverage for custom schema functionality including defaults, QB queries, and validation
packages/schema/src/schema.ts	Extended DataSourceProvider type to include optional defaultSchema field
packages/sdk/src/ts-schema-generator.ts	Modified provider object generation to include defaultSchema in TypeScript schema output
packages/orm/src/client/executor/zenstack-query-executor.ts	Added check for custom PostgreSQL schemas to enable name mapping
packages/orm/src/client/executor/name-mapper.ts	Implemented schema name resolution and injection into SQL queries via TableNode.createWithSchema
packages/language/src/validators/datasource-validator.ts	Added validation for defaultSchema and schemas fields to ensure PostgreSQL-only usage
packages/language/src/validators/attribute-application-validator.ts	Added validation for @@schema attribute to verify schema names are declared in datasource
packages/testtools/src/schema.ts	Added placeholder replacement function for test schemas
packages/testtools/src/client.ts	Updated to preserve provider object properties when replacing provider type
packages/language/res/stdlib.zmodel	Uncommented and updated documentation for @@schema attribute

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[claude]

Claude finished @ymc9's task —— View job

---

PostgreSQL Custom Schema Support - Code Review

Reviewing PR #385 which adds PostgreSQL custom schema support to ZenStack.

Review Tasks

• Analyze overall architecture and implementation approach
• Review language/validation layer changes
• Evaluate ORM integration and query generation
• Assess code generation and schema handling
• Review test coverage and quality
• Identify security, performance, and architectural concerns
• Provide comprehensive feedback and recommendations

---

Summary of Changes

This PR introduces comprehensive PostgreSQL custom schema support through:

1. Language Support: Added @@schema attribute and defaultSchema/schemas datasource fields
2. Validation: Proper validation for PostgreSQL-specific schema features
3. ORM Integration: Schema-aware query generation and table name mapping
4. Code Generation: Schema information propagated to TypeScript schema output
5. Comprehensive Testing: E2E tests covering various schema scenarios

✅ Strengths

1. Comprehensive Implementation

• Proper Langium Integration: Clean AST updates in stdlib.zmodel with correct attribute definitions
• Type Safety: Strong typing with schema information in the DataSourceProvider type
• Database Abstraction: Schema handling isolated to PostgreSQL provider only

2. Robust Validation Logic (packages/language/src/validators/)

• Provider Validation: Schema features correctly restricted to PostgreSQL only
• Schema Reference Validation: Validates @@schema references against defined schemas in datasource
• Error Messages: Clear, actionable error messages for schema misuse

3. Excellent ORM Implementation (packages/orm/)

• Performance Optimized: Name mapper only instantiated when needed (schemas or mapped names exist)
• Query Correctness: Proper handling of schema-qualified table names using Kysely's TableNode.createWithSchema()
• SQL Generation: Clean schema qualification in generated SQL ("schema"."table")

4. Thorough Test Coverage

The test suite is comprehensive and well-designed:

• Default Behavior: Verifies 'public' schema is used by default
• Custom Schema: Tests both ORM and QB queries with custom schemas
• Validation: Error cases for non-PostgreSQL providers and undefined schemas
• Real DB Integration: Uses usePrismaPush for realistic testing

⚠️ Critical Issues Found

1. @@Schema Positional Argument Bug (Critical)

Location: packages/orm/src/client/executor/name-mapper.ts:396-400

The current implementation only looks for named arguments, but @@schema is defined with a positional parameter:

// Current broken logic - ignores @@schema("myschema")
const nameArg = schemaAttr.args?.find((arg) => arg.name === 'name');

Impact: All model-specific schema annotations are ignored, always falling back to default schema.

Fix Required:

const schemaArg = schemaAttr.args?.find((arg) => !arg.name || arg.name === 'name');
if (schemaArg?.value.kind === 'literal') {
    schema = schemaArg.value.value as string;
}

2. Default Schema Never Activates (Critical)

Location: packages/orm/src/client/executor/zenstack-query-executor.ts:58-63

If only defaultSchema is set (no @@schema attributes), the name mapper is never instantiated:

// Current logic misses defaultSchema-only scenarios
if (this.schemaHasCustomPostgresSchema(client.$schema) || this.schemaHasMappedNames(client.$schema)) {
    this.nameMapper = new QueryNameMapper(client.$schema);
}

Impact: Queries against PostgreSQL with only defaultSchema fail because tables aren't schema-qualified.

Fix Required: Add check for provider.defaultSchema.

3. Validation Logic Error (High)

Location: packages/language/src/validators/attribute-application-validator.ts:343

Using invariant() will crash the validator instead of reporting a validation error:

invariant(schemaName, `@@schema expects a string literal`); // Crashes!

Fix Required: Use accept() for validation errors, not invariant().

4. Provider Metadata Loss (Medium)

Location: packages/testtools/src/client.ts:82-88

The test infrastructure overwrites provider metadata, breaking PostgreSQL schema tests:

provider: {
    type: provider, // Loses defaultSchema field
}

Fix Required: Preserve existing provider fields with spread operator.

🔍 Code Quality Assessment

Architecture: ✅ Excellent

• Clean separation of concerns across language, validation, ORM, and code generation layers
• Proper abstraction with PostgreSQL-specific functionality isolated
• Well-structured AST integration following Langium patterns

Error Handling: ⚠️ Needs Improvement

• Good comprehensive validation coverage
• Critical bug: Using invariant() instead of accept() for validation errors
• Missing graceful fallback handling for malformed schemas

Performance: ✅ Good

• Efficient implementation with conditional name mapper activation
• Schema resolution cached appropriately
• Minimal overhead when schemas not used

Testing: ✅ Excellent

• Comprehensive coverage of all scenarios including edge cases
• Real database integration with usePrismaPush
• Clear test structure with proper isolation

Security: ✅ Good

• No obvious vulnerabilities detected
• Proper validation of schema names
• SQL injection protection handled by Kysely

📋 Additional Recommendations

1. Enhanced Type Safety

// Consider using enums instead of string literals
enum DatabaseProvider {
    POSTGRESQL = 'postgresql',
    SQLITE = 'sqlite'
}

2. Documentation Improvements

• Add inline documentation for complex logic in name-mapper.ts
• Document migration patterns for existing databases
• Consider JSDoc for schema resolution methods

3. Performance Optimizations

// Cache name mapper instances per schema
private static mapperCache = new WeakMap<SchemaDef, QueryNameMapper>();

4. Error Message Consistency

Ensure error messages are consistent across validation rules and include helpful context.

🚀 Production Readiness

After fixing the critical issues, this feature will be production-ready. The implementation is well-architected and provides solid foundation for PostgreSQL multi-schema deployments.

Priority Fixes Required:

1. Fix positional argument handling in getTableSchema()
2. Add default schema support to executor constructor
3. Replace invariant() with accept() in validation
4. Preserve provider metadata in test infrastructure

---

Overall Assessment: Well-implemented feature with excellent architecture, but critical bugs must be fixed before merge.

---