This reverts commit fb35f93.

Bq custom partitioning cdk

…g-cdk

Fix BigQuery destination check with default partitioning field

…llision with a source column named row_number

selectDedupedRecords() builds the MERGE's USING subquery as two CTEs: `records`
selects the stream's columns explicitly, then `numbered_rows` does SELECT * over it
and hangs a row_number() window function on top, aliased `row_number`. When the
source stream itself carries a column named `row_number`, both identifiers land in
the same scope and every later reference is ambiguous -- the outer SELECT column
list and the trailing WHERE row_number = 1 -- so the MERGE aborts with
"Column name row_number is ambiguous". Incremental append+deduped syncs of any table
carrying that column name cannot complete, and the stock workarounds (drop the
column, or switch the stream off dedup) both cost a full resync.

v1 renames the window alias to `_airbyte_dedup_row_number`, inside the `_airbyte_`
prefix already reserved for destination metadata columns, and updates the single
reference in the WHERE clause. The row_number() invocation itself is unchanged.

The alias never reaches the final table: the outer SELECT enumerates columns
explicitly, so numbered_rows' extra column is projected away before the MERGE sees
new_record. Final table schema, staging tables and connection state are all
untouched, so this ships without a resync.

Trade-off: the alias is a constant, so a source column literally named
`_airbyte_dedup_row_number` would reintroduce the collision. Deriving it from the
stream schema would close that hole at the cost of making the generated SQL
stream-dependent.

Upstream issue, open and unfixed: #45855

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

…-patch-v1

destination-bigquery rownum v1: rename dedup window alias to avoid co…