kristiandupont/extract-pg-schema

Support for arrays

jcristovao opened this issue · 4 comments

Hello,

I've noticed a bug/limitation on kanel - it does not properly support arrays, either of regular types or of enums...

... but I'm thinking that perhaps the fix needs to start on this module. Would it make sense to add an extra (boolean) field to the column object indicating when a column is an array isArray (as a shortcut to rawInfo.data_type === 'ARRAY')?

Another thing to consider, for which I don't have a really clean suggestion is that postgres renames the type of arrays of custom types to _customType

Array Types
Whenever a user-defined type is created, PostgreSQL automatically creates an associated array type, whose name consists of the element type's name prepended with an underscore

Source

Should we drop the underscore from the type, but put the isArray flag to true?

This way the type translation of kanel would mostly work, and we would just have to had some code to insert the type[] if isArray === true

What do you think?

Ah yes, I haven't ever used arrays in my databases so I've not made any effort to support them. I will look into this.

I've published a version that supports arrays (only single-dimension ones though. It seems that it has limited support for multidimensional arrays, let me know if you need that). You should be able to add the array types to your customTypeMap config property in Kanel now. Let me know if this helps!

Hey! Sorry, I never came back to this, other priorities...

Thank you, I see that now arrays have some level of support (I personally don't mind it's single dimension, that's what I use).

However, this change is not enough for us. We use not only 'base' type arrays (like text[] and bigint[]) but also enum arrays.
We have a source enum array, for example, that Kanel correctly represents with source[], but then it's missing the import of the associated typescript for the enum.

I've done some changes on my forks to address this (enough for my use case), but they probably don't follow your preferred approach, let me know what you think:

master...Optylon:master

kristiandupont/kanel@master...jcristovao:master

That looks like a nice change. Would you mind creating a PR out of it, then I will get it merged.