jasonlin45 commented on issue #3449: URL: https://github.com/apache/arrow-adbc/issues/3449#issuecomment-3321468464
>However, one good reason I can come up with to separate the vendor+type tuple out into separate fields is if it's anticipated that there may be more vendor-specific information and we don't want to make clients repeat themselves. I agree with this point, clients could then in theory switch on the vendor code to make processing easier. However, the information itself cannot be interpreted in a vacuum and these must always be coupled. `OpaqueType` canonicalizes this coupling, but Field metadata is just a string map without any guardrails. Perhaps the client repetition of these vendor is a necessary evil? >SNOWFLAKE:type, BIGQUERY:type, DATABRICKS:type... this makes it clear that the interpretation of the SQL string can only be done reliably considering the specific dialect. Because we NEED to understand the backend this came from in order to interpret this field at all, coupling this information makes sense to me. If this information is somehow dropped at all for a user, then this field cannot be interpreted correctly unless namespaced. -- 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]
