GH-43640: [Go] allow setting Logical types for pqarrow file writer

[datbth]

Rationale for this change

What changes are included in this PR?

Are these changes tested?

yes

Are there any user-facing changes?

• GitHub Issue: [Go] pqarrow - Provide a way to support Parquet Logical types that do not have or need Arrow equivalent types #43640

[github-actions]

Thanks for opening a pull request!

If this is not a minor PR. Could you open an issue for this pull request on GitHub? https://github.com/apache/arrow/issues/new/choose

Opening GitHub issues ahead of time contributes to the Openness of the Apache Arrow project.

Then could you also rename the pull request title in the following format?

GH-${GITHUB_ISSUE_ID}: [${COMPONENT}] ${SUMMARY}

or

MINOR: [${COMPONENT}] ${SUMMARY}

In the case of PARQUET issues on JIRA the title also supports:

PARQUET-${JIRA_ISSUE_ID}: [${COMPONENT}] ${SUMMARY}

See also:

• Other pull requests
• Contribution Guidelines - Contributing Overview

[github-actions]

⚠️ GitHub issue #43640 has been automatically assigned in GitHub to PR creator.

[joellubi]

Maybe instead of adding a function parameter here we could optionally specify the logical type in ColumnProperties which can be accessed per-column through the existing props parameter.

[datbth]

I think that would be confusing for the parquet APIs.
When writing parquet files, logical types should be specified right when creating the parquet schema.
This extra parameter is only relevant for pqarrow only so I think it should be within the scope of pqarrow.

Perhaps I can pass it down via pqarrow.ArrowWriterProperties instead?

[datbth]

^ changed in ef9f2f6

[joellubi]

The length here should come from the physical layout. The LogicalType interface has method IsApplicable(t parquet.Type, tlen int32) bool that can validate whether the underlying type is of the right size for the logical type.

In practice this means you shouldn't need to specify the length here at all. The arrow types above that correspond to FixedLenByteArray should already be setting length to the appropriate value.

That raises another point. If schema.LogicalType is actually the only field that the new LogicalType struct needs to track, then we can skip defining the new struct type and just use the schema.LogicalType interface instead.

[datbth]

Thanks for explaining.
I have updated to use schema.LogicalType directly 3de0781

[datbth]

closing in favor of #43679