The GeoPackage standard is a lit loose on the recommendation for maximum identifier length. This is something that should be strengthened in the recommendation statement in section 1.0 of the document where base definitions of the SQLite container are defined.
The current recommendation text block reads:
SQLite is more flexible with regards to identifiers than many other RDBMS systems. If GeoPackage data is to be used in other RDBMS systems, standard practices SHOULD be used to reduce potential interoperability risks. For maximum interoperability, all user-defined GeoPackage table, view, column, trigger, and constraint name values SHOULD start with a lowercase character and only include lowercase characters, numbers 0-9, and underscores (_). In addition, some RDBMS systems truncate identifier names that are longer than a fixed byte length which may be as short as 30 bytes. Therefore, long GeoPackage identifier values SHOULD be avoided and if long identifier values are used, then they SHOULD be unique for at least the first 30 bytes.
For interoperability, 128 characters is a common maximum length for SQL-92 implementations - it is suggested that the above text block be modified to add "exceeding 128 characters" (in bold in the last sentence) as follows:
SQLite is more flexible with regards to identifiers than many other RDBMS systems. If GeoPackage data is to be used in other RDBMS systems, standard practices SHOULD be used to reduce potential interoperability risks. For maximum interoperability, all user-defined GeoPackage table, view, column, trigger, and constraint name values SHOULD start with a lowercase character and only include lowercase characters, numbers 0-9, and underscores (_). In addition, some RDBMS systems truncate identifier names that are longer than a fixed byte length which may be as short as 30 bytes. Therefore, long GeoPackage identifier values exceeding 128 characters SHOULD be avoided and if long identifier values are used, then they SHOULD be unique for at least the first 30 bytes.
This should not have any compatibility issues with GeoPackage versions - it's simply reinforcing best practice for interoperability.
The GeoPackage standard is a lit loose on the recommendation for maximum identifier length. This is something that should be strengthened in the recommendation statement in section 1.0 of the document where base definitions of the SQLite container are defined.
The current recommendation text block reads:
SQLite is more flexible with regards to identifiers than many other RDBMS systems. If GeoPackage data is to be used in other RDBMS systems, standard practices SHOULD be used to reduce potential interoperability risks. For maximum interoperability, all user-defined GeoPackage table, view, column, trigger, and constraint name values SHOULD start with a lowercase character and only include lowercase characters, numbers 0-9, and underscores (_). In addition, some RDBMS systems truncate identifier names that are longer than a fixed byte length which may be as short as 30 bytes. Therefore, long GeoPackage identifier values SHOULD be avoided and if long identifier values are used, then they SHOULD be unique for at least the first 30 bytes.
For interoperability, 128 characters is a common maximum length for SQL-92 implementations - it is suggested that the above text block be modified to add "exceeding 128 characters" (in bold in the last sentence) as follows:
SQLite is more flexible with regards to identifiers than many other RDBMS systems. If GeoPackage data is to be used in other RDBMS systems, standard practices SHOULD be used to reduce potential interoperability risks. For maximum interoperability, all user-defined GeoPackage table, view, column, trigger, and constraint name values SHOULD start with a lowercase character and only include lowercase characters, numbers 0-9, and underscores (_). In addition, some RDBMS systems truncate identifier names that are longer than a fixed byte length which may be as short as 30 bytes. Therefore, long GeoPackage identifier values exceeding 128 characters SHOULD be avoided and if long identifier values are used, then they SHOULD be unique for at least the first 30 bytes.
This should not have any compatibility issues with GeoPackage versions - it's simply reinforcing best practice for interoperability.