[maharanay22]

Description

When a PostgreSQL datasource has a schema parameter, PostgresHandler.connect() runs SET search_path TO "<schema>", public and never checks that the schema exists. PostgreSQL accepts a search_path entry for a schema that isn't there, so a mistyped or wrong-cased schema is silently skipped and every unqualified query reads from public instead

The schema name is double-quoted in that statement, so it is case-sensitive. A common way to hit this is schema: "sales" when the real schema is "Sales". In that case check_connection() still reports success, SELECT * FROM orders returns public.orders (a different table with different rows), and nothing in the response says anything went wrong. A schema that doesn't exist at all behaves the same way

This change looks the schema up in pg_namespace right after connecting. If it isn't found, the handler raises psycopg.errors.InvalidSchemaName with a message that names the schema and the database and says schema names are case-sensitive. Since this is a psycopg.Error, check_connection() now fails with that message. The connection is also closed when setup fails after psycopg.connect() succeeded, so a failed setup no longer leaves a connection open

Datasources whose schema exists are not affected. Datasources that were configured with a wrong schema will now fail to connect instead of quietly reading public, which is the point of the fix

Fixes: no linked issue, because issues are turned off for this repository. The bug is described in full above

Type of change

• Bug fix (non-breaking change which fixes an issue)

Verification Process

To ensure the changes are working as expected:

• Test Location: tests/unit/handlers/test_postgres.py (new test_connect_with_missing_schema_fails, updated test_connect_with_schema_sets_search_path_after_connection), plus a manual check against a real PostgreSQL 16.2 server
• Verification Steps: create a schema "Sales" with orders(id) holding 1, and public.orders(id) holding 999. Then connect with schema set to Sales, sales and nonexistent, call check_connection() and run SELECT * FROM orders

Before (current main):

schema='Sales'        check_connection.success=True error=None
                      SELECT * FROM orders -> [{'id': 1}]
schema='sales'        check_connection.success=True error=None
                      SELECT * FROM orders -> [{'id': 999}]
schema='nonexistent'  check_connection.success=True error=None
                      SELECT * FROM orders -> [{'id': 999}]

After:

schema='Sales'        check_connection.success=True error=None
                      SELECT * FROM orders -> [{'id': 1}]
schema='sales'        check_connection.success=False error='Schema "sales" does not exist in database "postgres". Schema names are case-sensitive.'
                      SELECT * FROM orders -> raised InvalidSchemaName: Schema "sales" does not exist in database "postgres". Schema names are case-sensitive.
schema='nonexistent'  check_connection.success=False error='Schema "nonexistent" does not exist in database "postgres". Schema names are case-sensitive.'
                      SELECT * FROM orders -> raised InvalidSchemaName: Schema "nonexistent" does not exist in database "postgres". Schema names are case-sensitive.

Unit tests. The new test fails on main and passes with the fix:

# main
FAILED tests/unit/handlers/test_postgres.py::TestPostgresHandler::test_connect_with_missing_schema_fails
E       AssertionError: InvalidSchemaName not raised
1 failed, 32 passed, 1 skipped

# this branch
33 passed, 1 skipped

ruff check and ruff format --check (0.11.11) pass on the changed files. No dependencies changed

Additional Media:

• I have attached a brief loom video or screenshots showcasing the new functionality or change.

I didn't record a video or take screenshots. The before and after terminal output above shows the change instead

Checklist:

• My code follows the style guidelines(PEP 8) of MindsDB.
• I have appropriately commented on my code, especially in complex areas.
• Necessary documentation updates are either made or tracked in issues.
• Relevant unit and integration tests are updated or added.

No documentation change is needed. The README already describes schema as "The database schema to use", and the handler now enforces that

I used an AI assistant to help investigate this and draft the change and tests, and I reviewed and tested it myself