twuebi opened a new pull request, #1051:
URL: https://github.com/apache/arrow-go/pull/1051

   ## Rationale
   
   Since #1028, the reader reconstructs an extension type directly from a 
Parquet logical type (via `ArrowTypeFromParquet`), so the *inferred* field can 
now be an extension type rather than the bare storage type it used to be. 
`applyOriginalStorageMetadata` still assumed the inferred type was plain 
storage when reconciling against the stored `ARROW:schema`, so when the two 
extension instances differed it fell into the "wrap the storage type" branch, 
found an extension instead of the storage type, and raised a spurious 
storage-type mismatch.
   
   This surfaces with GeoArrow WKB: an `authority_code` CRS (e.g. the default 
`OGC:CRS84`) round-trips through Parquet's opaque CRS string and comes back 
tagged `srid`, so the inferred `WKBType` differs from the one stored in 
`ARROW:schema`. Reading any such file — even though the stored schema is 
authoritative and correct — failed with:
   
   ```
   invalid: mismatch storage type 'extension_type<storage=binary>' for 
extension type 'extension_type<storage=binary>'
   ```
   
   ## Fix
   
   In `applyOriginalStorageMetadata`'s extension branch, when the inferred type 
is already an extension of the same name as the origin's, adopt the origin's 
(authoritative) parameters instead of requiring the inferred type to be the 
bare storage type.
   
   ## Testing
   
   Existing `pqarrow` extension/geospatial/store-schema tests pass; verified 
end-to-end that a GeoArrow WKB file with default-CRS (`authority_code`) columns 
and a stored `ARROW:schema` now reads back correctly.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to