[BUG]: Consider changing signature of UniqueOnConstraintBuilder::on to allow more convenient spreading

[mawallace]

What version of drizzle-orm are you using?

0.30.10

What version of drizzle-kit are you using?

0.21.4

Describe the Bug

The pg UniqueOnConstraintBuilder has the following signature for the on method:

on(...columns: [PgColumn, ...PgColumn[]]): UniqueConstraintBuilder;

I want to do something like this (to keep my uniqueness constraint synced with a particular set of fields):

export const unit = backend.table('unit', {
  id: uuid('id').primaryKey().defaultRandom(),
  ...ADDRESS_FIELDS,
}, (t) => {
  const addressColumns = Object.entries(t)
    .filter(([k, _v]) => (Object.keys(ADDRESS_FIELDS).includes(k)))
    .map(([_k, v]) => (v));
  const unique_address = unique('unique_address').on(...addressColumns);

  return { unique_address };
});

However, I get the error

A spread argument must either have a tuple type or be passed to a rest parameter.

Instead, I'm forced to do this:

export const unit = backend.table('unit', {
  id: uuid('id').primaryKey().defaultRandom(),
  ...ADDRESS_FIELDS,
}, (t) => {
  // Get all address columns.
  const addressColumns = Object.entries(t)
    .filter(([k, _v]) => (Object.keys(ADDRESS_FIELDS).includes(k)))
    .map(([_k, v]) => (v));
  if (addressColumns.length === 0) {
    throw new Error('Must be at least 1 address column.');
  }
  const unique_address = unique('unique_address')
    .on(addressColumns[0]!, ...addressColumns.slice(1));

  return { unique_address };
});

It's not the worst thing in the world, but it would certainly be cleaner to do the former. This would be possible if the signature was instead

on(...columns: PgColumn[]): UniqueConstraintBuilder;

I'm guessing the motivation for the current signature is to prevent 0-argument calls to on, which makes sense. If you adopted the suggestion, there would need to be some well-defined/document behavior for 0-argument calls (i.e., not make any constraint, throw an error, etc.).

Totally understand if you want to keep it the way it is, but wanted to make you aware of this use case in case you wanted to adopt the suggestion or had any other ideas to make it easier to do something like this.

Expected behavior

No response

Environment & setup

No response