Studio SQL Export Can Silently Swap Values For Numeric Column Names

JavaScript object property enumeration orders integer-like keys first, regardless of insertion order. The formatter uses Object.values(row) (after deleting row.idx), which returns values in that enumerable order, not in the order defined by table.columns. For tables with numeric string column names, this misaligns values to columns. Additionally, unconditionally deleting row.idx removes a legitimate column if present, reducing the value count.

1. Create table: create table public.yearly_totals (id bigint, "2024" bigint, "2023" bigint); insert into public.yearly_totals values (7, 99, 42); 2. In Studio Table Editor, use Copy as SQL or Export as SQL. 3. Observe generated INSERT: VALUES (42, 99, 7) instead of (7, 99, 42), so restore produces wrong values.

If table.columns includes a column not present in the row object (e.g., schema drift or partial row data), row[col.name] is undefined and produces NULL, potentially hiding data loss. Ensure rows are complete or validate before export. Concurrent schema changes between metadata fetch and row retrieval can still cause misalignment; snapshot both together. Escaping logic assumes PostgreSQL dialect; cross-database export may need adjustments. Rollback: if this fix introduces regressions, reverting to the previous version will reintroduce the silent corruption bug; instead, use a manual export script that explicitly maps columns until a patched release is available.