perf(postgrest): optimize select column normalization

[astelmach01]

Summary

• Replaces select() column cleanup with a single-pass implementation that avoids split/map/join allocations.
• Preserves quoted identifier whitespace behavior and returns the original column string when no cleanup is needed.
• Adds a focused PostgREST query-builder test for whitespace removal and quoted identifiers.

Performance

Local microbenchmark on Node v23.7.0, 1,000,000 iterations per case:

• *: 68.1ms -> 12.9ms, 5.27x faster
• id,name,email,created_at: 679.8ms -> 285.7ms, 2.38x faster
• formatted select with quoted identifier: 1324.9ms -> 486.1ms, 2.73x faster
• nested select: 2018.3ms -> 942.5ms, 2.14x faster

Validation

• npx jest test/query-builder.test.ts --runInBand
• npm run type-check --workspace=@supabase/postgrest-js
• npx prettier --check packages/core/postgrest-js/src/PostgrestQueryBuilder.ts packages/core/postgrest-js/test/query-builder.test.ts

Note: full npm run format:check --workspace=@supabase/postgrest-js currently reports an unrelated existing formatting issue in packages/core/postgrest-js/test/rpc.test.ts.

[pkg-pr-new]

Open in StackBlitz

@supabase/auth-js

npm i https://pkg.pr.new/@supabase/auth-js@2334

@supabase/functions-js

npm i https://pkg.pr.new/@supabase/functions-js@2334

@supabase/postgrest-js

npm i https://pkg.pr.new/@supabase/postgrest-js@2334

@supabase/realtime-js

npm i https://pkg.pr.new/@supabase/realtime-js@2334

@supabase/storage-js

npm i https://pkg.pr.new/@supabase/storage-js@2334

@supabase/supabase-js

npm i https://pkg.pr.new/@supabase/supabase-js@2334

commit: eee12c9

[mandarini]

Hello @astelmach01, thanks for taking the time to dig into this and for the thorough benchmark. Before going further, I want to ask one thing: did you hit removeWhitespaceExceptQuoted (or rather, the inline split/map/join it's replacing) as a real bottleneck in a profile of an actual workload? Or is the motivation the microbenchmark numbers? The reason I ask: this function runs once per query, right before an HTTP request to PostgREST that typically takes anywhere from a few milliseconds to a few hundred milliseconds. The per-call savings here are in the sub-microsecond to ~1 μs range, which is well below the noise floor of the surrounding network call, so the "2–5x faster" headline, while accurate as a ratio, won't translate into anything measurable in real usage. On the other side, the new implementation is a bit more code with more state to keep in your head (the lastKeptIndex bookkeeping), where the original split/map/join is idiomatic and obviously correct at a glance. For a code path that isn't hot in practice, I'd lean toward keeping the simpler version.

If you've got a real-world profile where this shows up (a tight loop, a server building many queries per request, anything like that) I'd love to see it and I'll happily reconsider. Otherwise I think I am a bit reluctant to go forward with this change, as it adds in complexity. Either way, genuinely appreciate the contribution and the care you put into the PR.