fix(tags): convert postgres enum type to varchar

[nytai]

SUMMARY

The original tags migration ended up using native postgres enums for some columns. This can cause issues since updates to the enum require a migration to alter the enum type (more info here). This lack of flexibility makes using postgres enums challenging. Converting the column types to varchar and allowing SQL Alchemy to handle to enum type should be fine and give us the most flexibility moving forward to add other tag types.

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

TESTING INSTRUCTIONS

ADDITIONAL INFORMATION

• Has associated issue:
• Required feature flags:
• Changes UI
• Includes DB Migration (follow approval process in SIP-59)
  • Migration is atomic, supports rollback & is backwards-compatible
  • Confirm DB migration upgrade and downgrade tested
  • Runtime estimates and downtime expectations provided
• Introduces new feature or API
• Removes existing feature or API

[codecov]

Codecov Report

Merging #23526 (c3d5841) into master (81b32d1) will not change coverage.
The diff coverage is n/a.

❗ Current head c3d5841 differs from pull request most recent head be2af78. Consider uploading reports for the commit be2af78 to get more accurate results

@@           Coverage Diff           @@
##           master   #23526   +/-   ##
=======================================
  Coverage   67.68%   67.68%           
=======================================
  Files        1914     1914           
  Lines       73928    73928           
  Branches     8021     8021           
=======================================
  Hits        50036    50036           
  Misses      21849    21849           
  Partials     2043     2043           

Flag	Coverage Δ
hive	52.73% <ø> (ø)
mysql	78.48% <ø> (ø)
postgres	78.54% <ø> (ø)
presto	52.65% <ø> (ø)
python	82.39% <ø> (ø)
sqlite	77.05% <ø> (ø)
unit	52.63% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[villebro]

LGTM, thanks for fixing this; I also ran into this issue while doing some testing and figured this is likely the best path forward. The only downside I can see is a minor perf hit, but we can add an index to the column if that becomes an issue. For similar future cases we should maybe consider just using some variant of TINYINT/SMALLINT/INT that maps to a class MyEnum(int, Enum) in the backend.