fix(drizzle): truncate PostgreSQL identifiers exceeding 63-char limit #14637
+300
−28
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.
What?
PostgreSQL identifiers exceeding 63 characters cause migration failures when combining nested arrays, localization, and versioning. Names like
_users_v_version_ingredient_sections_section_ingredients_locale_idx(68 chars) get silently truncated by PostgreSQL, breaking subsequent migrations that reference the full name.Why?
Direct string concatenation in
traverseFields.tsbypassed existing truncation utilities (buildIndexName,buildForeignKeyName), creating identifiers that exceeded the limit.How?
Applied truncation helpers consistently across all index and foreign key name generation:
Array fields:
${arrayTableName}_order_idx→buildIndexName({ name: ${arrayTableName}_order, adapter })${arrayTableName}_parent_id_fk→buildForeignKeyName({ name: ${arrayTableName}_parent_id, adapter })_localeindexesBlock fields:
_order,_parent_id,_path, and_localeindexes_parent_idforeign keysSelect fields:
order,parent,locale, andvalueindexesparentforeign keysHelpers truncate to 60 chars (leaving room for suffixes like
_idx,_fkand numbering for duplicates), ensuring compliance with PostgreSQL's 63-char limit.Fixes #9649
Warning
Firewall rules blocked me from connecting to one or more addresses (expand for details)
I tried to connect to the following addresses, but was blocked by firewall rules:
127.0.0.118.8.8.8analytics.localstack.cloud/opt/code/localstack/.venv/bin/python -m localstack.runtime.main(dns block)api.localstack.cloud/opt/code/localstack/.venv/bin/python -m localstack.runtime.main(dns block)assets.localstack.cloud/opt/code/localstack/.venv/bin/python -m localstack.runtime.main(dns block)fastdl.mongodb.orgnode ./postinstall.js(dns block)localhost.localstack.cloud/opt/code/localstack/.venv/bin/python /opt/code/localstack/.venv/bin/localstack status services --format=json(dns block)If you need me to access, download, or install something from one of these locations, you can either:
Original prompt
This section details on the original issue you should resolve
<issue_title>Payload creates too long names/identifiers for postgress</issue_title>
<issue_description>### Describe the Bug
Given I use payload with a postgress database
When combining features like nested arrays, localization and versioning
Then payload creates too long index and table names like
_users_v_version_ingredient_sections_section_ingredients_locale_idxThen Postgress like Neon with Vercel then truncates this to use only the first 63 chars
And that creates all sorts of problems (I assume)
On my end this surfaced when I removed some of the features that created the long index
Thereby creating a migration dropping the index and altering tables
Which postgress takes only 63 chars of thereby failing.
Link to the code that reproduces this issue
https://github.com/Xiphe/payload-long-index-names
Reproduction Steps
pnpm installpnpm payload migrateWhich area(s) are affected? (Select all that apply)
db-postgres
Environment Info