Support for `ARRAY` column types? about mammoth HOT 6 CLOSED

BTW, I've been using this array helper and it seems to work:

const array = <T>(elementType: ColumnDefinition<T>): ColumnDefinition<Array<T>> =>
    dataType<Array<T>>(elementType + '[]');

from mammoth.

I added the array helper as you suggested, thanks.

I also added a raw expression helper so you have your escape hatch.

The changes are on master and will be included in the next version. Also, I'll update the docs.

from mammoth.

Not yet, but I can add this in. In the meantime you should be able to use dataType<string[]>('text[]') to achieve this.

I do wonder how to support multi-dimensional arrays. I did see some APIs use e.g. [text()] or [[text()]]. Or there should be an array2d(), etc. What do you think?

For reference there are probably some more array functions which should be taken into account at some point: https://www.postgresql.org/docs/12/arrays.html.

from mammoth.

Thanks for the workaround. Will use that.

I haven't thought much about multi-dimensional arrays, but my first instinct would be array(array(text()).

For reference there are probably some more array functions which should be taken into account at some point: https://www.postgresql.org/docs/12/arrays.html.

Tangent: Is there a general purpose "escape hatch" in Mammoth to add stuff verbatim to the query? Similar to how I can define my own data type with dataType, is there a way to call obscure Postgres operators and functions even if Mammoth doesn't yet have built-in support for them?

from mammoth.

Great. I'll try to find some time to get this supported in the lib itself.

Tangent: Is there a general purpose "escape hatch" in Mammoth to add stuff verbatim to the query? Similar to how I can define my own data type with dataType, is there a way to call obscure Postgres operators and functions even if Mammoth doesn't yet have built-in support for them?

No, but it's a good suggestion. Something like a raw or unsafe expression e.g. Unsafe<T>(sql: string) or maybe safer something like string literal helper so you can call:

db
  .select(star())
  .from(db.foo)
  .where(raw<T>`col obscure operator = ${value}`)

or

db
  .select(raw<T>`unsupported expression`)
  .from(db.foo)

What do you think?

from mammoth.

I don't have any experience with tagged template literals, so I don't really know the pros/cons.

Seems reasonable, though. The Zapatos library uses them: docs link.

from mammoth.