fix(schema-engine): Fixed introspecting enum array types #5211
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Issue
prisma/prisma#22456
Affected databases
Root cause
PostgreSQL prepends an underscore to produce ARRAY types from each type defined. (The enum is defined as a type.) The database introspection code trimmed all underscores from the type name of the column, which resulted in a loss of the underscore in the name of the original enum type. As a consequence the enum type was not found and ended up as unsupported. The unsupported type did not match the original type, resulted in a unwanted migration.
Solution
Remove only a single underscore prefix from the type name.
Remarks
Quoting from the PostgreSQL CREATE TYPE documentation:
Unrelated to the underscore prefix problem, but will affect the generality of any solution: By default
NAMEDATALEN
is 63. It can be queried bySHOW max_identifier_length;
If the original type name was
NAMEDATALEN
long, then the last character would be truncated by PostgreSQL. It would still prevent finding the correct type on introspection. A workaround could be made to search for a matching type. However, it is a very rare corner case, it is is not worth the additional code. Such cases could be fixed by increasingNAMEDATALEN
on the database side.