👋 I'm rudder-devbox. I opened this PR from a Linear ticket.

Mention @devbox or @rudder-devbox and I'll act on it — on a top-level PR comment,
in a review summary, or on an inline comment on the diff. Without a mention I won't see it.

@rudder-devbox With the recent changes, can we update the postgres integration as well.

Updated the Postgres integration as well. The Postgres SQL-building paths now use the shared warehouse identifier helpers instead of direct pq.QuoteIdentifier, composite partition-key quoting goes through the shared comma-separated identifier helper, and the schema existence lookup now uses a bind parameter for the namespace.

Validation:

• go test ./warehouse/integrations/postgres ./warehouse/utils
• go test ./warehouse/integrations/postgres -run 'Test(ColumnsWithDataTypesQuotesIdentifiers|CreateTableQuotesSchemaAndTableIdentifiers)$'
• git diff --check

Commit: e47314f

I fixed the CI failure and pushed the change.

Root cause from the Snowflake integration log: LoadUserTables created the users staging table with a quoted mixed-case name like "RUDDER_STAGING_USERS_291ed6a224b24369b0eb46c0b527fa76", but the later deduplication MERGE read it as "TEST_TKZVPZVIFTFJ_1784497134".RUDDER_STAGING_USERS_291ed6a224b24369b0eb46c0b527fa76 without quoting the table identifier. Snowflake folded that unquoted identifier to uppercase and failed with 002003 (42S02): SQL compilation error: Object '...RUDDER_STAGING_USERS_291ED6A224B24369B0EB46C0B527FA76' does not exist or not authorized, and the test eventually timed out in TestIntegration/Event_flow/Upload_Job_with_Role.

Fix: quoted the Snowflake users MERGE target/source table identifiers with whutils.DoubleQuoteIdentifier, and fixed the adjacent append-mode temporary identifies table SQL to quote generated staging table identifiers instead of using Go %q.

Validation passed:

• go test ./warehouse/integrations/snowflake
• go test ./warehouse/utils
• git diff --check

Commit: ca04eb1

Codecov Report

❌ Patch coverage is 96.26308% with 25 lines in your changes missing coverage. Please review.
✅ Project coverage is 80.07%. Comparing base (c3c283c) to head (c99e78f).
⚠️ Report is 16 commits behind head on master.

@@            Coverage Diff             @@
##           master    #7187      +/-   ##
==========================================
- Coverage   80.13%   80.07%   -0.07%     
==========================================
  Files         595      596       +1     
  Lines       66151    66442     +291     
==========================================
+ Hits        53011    53201     +190     
- Misses      10021    10096      +75     
- Partials     3119     3145      +26     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

@achettyiitr shouldn't there be any updates in each warehouse test cases ?

@achettyiitr shouldn't there be any updates in each warehouse test cases ?

Nothing changes per integrations; currently, in some places, we were not using quoted identifiers, so we added those. With or without quote identifiers, SQL would work. Everything is covered in integration tests.

Remaining injection vector not covered by this pass — warehouse/integrations/deltalake/deltalake.go:571 (tableLocationQuery):

return fmt.Sprintf("LOCATION '%s/%s/%s'", externalLocation, d.Namespace, tableName)

d.Namespace / tableName are interpolated into a single-quoted string literal without escaping, so a value containing a ' breaks out of the literal. This is a string-literal context (needs warehouseutils.SQLStringLiteral on the segments), not identifier quoting — but since the PR hardened other literal contexts (schemaExists, fetchTables LIKE, etc.), leaving this one is an inconsistency worth closing or explicitly scoping out.

Low severity (namespace is config-controlled and it is a storage-path literal rather than DDL), but it is a genuine breakout path.

(Posted as a top-level comment because line 571 is outside this PR's diff, so GitHub could not anchor it inline.)

@achettyiitr shouldn't there be any updates in each warehouse test cases ?

Nothing changes per integrations; currently, in some places, we were not using quoted identifiers, so we added those. With or without quote identifiers, SQL would work. Everything is covered in integration tests.

@achettyiitr shouldn't there be any updates in each warehouse test cases ?

Nothing changes per integrations; currently, in some places, we were not using quoted identifiers, so we added those. With or without quote identifiers, SQL would work. Everything is covered in integration tests.

Integration Tests are covering only the happy path and proving current changes is not causing a regression. But we need negative test cases with malicious SQL's for proving that SQL has been hardened. In the previous Postgres PR, unit tests did that - so good to add for all warehouses too ?

Sandbox became unreachable (its file API was unavailable too long).