[Go] Allow duplicate field names in schemas and nested types

[asfimport]

Go's implementation of Schema panics if field names are duplicated within a schema. This is not guaranteed by the standard, so Go will not be able to handle valid record batches produced by other implementations which contain these.

https://github.com/apache/arrow/blob/084549a/go/arrow/schema.go#L117

Reporter: Ben Kietzman / @bkietz
Assignee: Sebastien Binet / @sbinet

PRs and other links:

• GitHub Pull Request #6580

_{Note: This issue was originally created as ARROW-8028. Please see the migration documentation for further details.}

[asfimport]

Wes McKinney / @wesm:
cc @sbinet

[asfimport]

Sebastien Binet / @sbinet:
I must say I fail to see the use case for a schema with multiple fields with the same name (and possibly with different data types).
and it seems more like an error that should be caught very early on.

[asfimport]

Wes McKinney / @wesm:
The project has so far taken the position that downstream applications are responsible for the enforcement of these kinds of metadata constraints. From the perspective of the Arrow protocol "data is data". In my experience duplicate field names do arise in practice and it's a slippery slope if Arrow implementations start making arbitrary (or otherwise opinionated) decisions about what to do with such data (whether disallowing them or otherwise disambiguating them by modifying the field names). APIs that presume field name uniqueness can raise an exception, though

[asfimport]

Sebastien Binet / @sbinet:
ok. I usually try to make defined behaviours very constrained (and then relaxing those if needed) as the opposite is a bit more convoluted to put in place.

[asfimport]

Francois Saint-Jacques / @fsaintjacques:

SELECT 1 AS one, 1 AS one;

[asfimport]

Sebastien Binet / @sbinet:
Issue resolved by pull request 6580
#6580

[asfimport]

Wes McKinney / @wesm:
Here's an example from the wild grafana/grafana-plugin-sdk-go#137 (comment)