Avoid adding a NullBuffer when decoding timestamp offsets #90
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Since 60288cd we applied an unary_opt kernel to decode timezones. This kernel always returns
Some
unless the date is outside the 1677-2262.Unfortunately, even though the kernel is unlikely to return
None
, applying the kernel always causes the resulting array to get aNullBuffer
, even if the source array did not have one.In order to avoid unnecessarily adding a
NullBuffer
, this commit first tries to apply a non-nullable kernel; and only falls back tounary_opt
in the rare case it fails.An alternative implementation that does not risk running the kernel twice would be to check the
NullBuffer
'snull_count
after running the kernel then strip it if itsnull_count
is zero; but it requires the unnecessary allocation of aNullBuffer
.