Repository navigation
Fix: PostGIS identifier length limit - #2
Merged
Merged
Conversation
AlexianMasson
force-pushed
the
fix/postgis-identifier-length-limit
branch
3 times, most recently
from
May 18, 2026 16:22
cc7d88b to
b1125b9
Compare
AlexianMasson
changed the title
Pull the 63-char bound out of the identifier regex and expose it as a max_length parameter on validate_postgres_identifier / validate_table_name, along with a matching max_length on sanitize_name. The defaults preserve PostgreSQL's standard 63-char cap so existing callers are unaffected; downstream callers that need tighter bounds (e.g. PostGIS table names that must leave room for an auto-created index suffix) can now opt in. Also removes a stray 'F' character left in validators.py docstring.
…hars to_postgis silently asks PostgreSQL to create an 'idx_<table>_<geom>' index even when index=False is set on the write. When the synthesized index name exceeds PostgreSQL's 63-char identifier limit, the whole write fails with: Error writing data to PostGIS table data.<long_name>: Identifier 'idx_<long_name>_geom' exceeds maximum length of 63 characters Enforce the derived 54-char cap (POSTGIS_TABLE_NAME_MAX_LENGTH) up-front: - write_data_to_postgis validates table_name against the tighter cap, so the failure surfaces immediately rather than mid-write. - get_available_table_name truncates the base name and reserves room for its numeric suffix using the same cap (replaces the magic '53'). - The process route runs the title through sanitize_name + validate at the PostGIS cap so user-supplied titles get truncated cleanly and an oversized name produces HTTP 400 instead of a runtime crash.
AlexianMasson
force-pushed
the
fix/postgis-identifier-length-limit
branch
from
May 19, 2026 07:29
b1125b9 to
a8951e7
Compare
tonio
approved these changes
May 19, 2026
| try: | ||
| validate_table_name(final_table_name, context="final") | ||
| validate_table_name( | ||
| final_table_name, context="final", max_length=POSTGIS_TABLE_NAME_MAX_LENGTH |
Contributor
There was a problem hiding this comment.
why not having POSTGIS_TABLE_NAME_MAX_LENGTH as the default param ? any other usecase I don't see ?
Collaborator
Author
There was a problem hiding this comment.
When we gonna create idx_<table>_geom spatial index, we should have max_length=PG_IDENTIFIER_MAX_LENGTH (more restrictive case, so the default value).
When not creating spatial index but just reading an existing table, we can have max_length=POSTGIS_TABLE_NAME_MAX_LENGTH.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Fix: PostGIS table-name length must leave room for auto-created spatial index
Problem
Writing a GeoDataFrame to PostGIS with a long table name failed with:
PostgreSQL caps identifiers at 63 characters. Even when
to_postgis(..., index=False)is set, PostGIS still auto-creates a spatial index namedidx_<table>_<geom_col>. If the synthesized index name exceeds 63 chars, the write fails mid-operation — after data has been streamed and after the user has already committed to that table name through the UI.Existing validators (
validate_postgres_identifier,validate_table_name) only enforced the raw 63-char limit on the table name itself, so a 60-char table name passed validation and then blew up at write time.Solution
Enforce the PostGIS-safe length cap up-front, derived from the geometry column convention:
Non-goals
sanitize_name's default cap stays at 63.validate_table_name(drop-table on rollback) still uses the default 63-char cap so legacy oversized tables remain droppable.Manual testing
Reproduce the original bug by ingesting a dataset whose sanitised title exceeds 54 characters:
Identifier '...' exceeds maximum length of 63 characterserror.idx_<table>_geomfits within the 63-char limit.If the user bypasses sanitisation (e.g. supplies a pre-validated name via the DB-import flow), the
write_data_to_postgisvalidator now rejects it up-front with a clear message identifying the offending length and the cap.