Alkis Evlogimenos
Alkis Evlogimenos
@Jens-G could you advise how to move this forward?
Awesome, thank you @Jens-G!
FYI if it was up to me I would move away from java style and go to all `//` comments. This means less rules to follow and they would be...
> I would be reluctant to merge this because it rewrites a lot of history. Of course, you can still get to it by referencing the previous commit, but for...
I marked this ready for review. I have tested offline that this method works as expected and has virtually no impact in parse speed of the original `FileMetaData` thrift message....
> Hi, can we perhaps find another term than "extension" for this feature? The reason is that we may also want to add support for extension types to Parquet (where...
> The point is to decouple the Thrift / Format spec from the definition of new extension (logical) types. It allows third-party definitions of such types and gradual standardization thereof...
@pitrou wdyt about calling the extensions in this PR "Metadata Extensions" vs the other ones "Type Extensions"? Would that clear it? Bonus is that if/when we add flatbuffers the extension...
> Perhaps "Binary protocol extensions" or "Unparsed protocol extensions"? "Metadata" is usually vague. Qualified as "Binary Protocol Extensions".
Friendly ping. Since there are no other comments can we merge this?