[jira] [Resolved] (PARQUET-903) C++: Add option to set RPATH to ORIGIN
[ https://issues.apache.org/jira/browse/PARQUET-903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wes McKinney resolved PARQUET-903. -- Resolution: Fixed Fix Version/s: cpp-1.0.0 Issue resolved by pull request 265 [https://github.com/apache/parquet-cpp/pull/265] > C++: Add option to set RPATH to ORIGIN > -- > > Key: PARQUET-903 > URL: https://issues.apache.org/jira/browse/PARQUET-903 > Project: Parquet > Issue Type: New Feature > Components: parquet-cpp >Reporter: Uwe L. Korn >Assignee: Uwe L. Korn > Fix For: cpp-1.0.0 > > > Made this an option as the actual RPATH value differs between OSX and Linux. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (PARQUET-907) Optionally store Page level metadata in the footer to enable predicate pushdowns
Julien Le Dem created PARQUET-907: - Summary: Optionally store Page level metadata in the footer to enable predicate pushdowns Key: PARQUET-907 URL: https://issues.apache.org/jira/browse/PARQUET-907 Project: Parquet Issue Type: Improvement Components: parquet-format Reporter: Julien Le Dem -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (PARQUET-906) add logical type timestamp with timezone (per SQL)
Julien Le Dem created PARQUET-906: - Summary: add logical type timestamp with timezone (per SQL) Key: PARQUET-906 URL: https://issues.apache.org/jira/browse/PARQUET-906 Project: Parquet Issue Type: Improvement Components: parquet-format Reporter: Julien Le Dem Priority: Minor We need to clarify the spec here. TODO: validate the following points. timestamp with timezone (per SQL) - each value has timezone - TZ can be different for each value -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (PARQUET-905) Add "Floating Timestamp" logical type
Julien Le Dem created PARQUET-905: - Summary: Add "Floating Timestamp" logical type Key: PARQUET-905 URL: https://issues.apache.org/jira/browse/PARQUET-905 Project: Parquet Issue Type: Improvement Components: parquet-format Reporter: Julien Le Dem Unlike current Parquet Timestamp stored in UTC, a "floating timestamp" has no timezone, it is up to the reader to interpret the timestamps based on their timezone. This is the behavior of a Timestamp in the sql standard -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (PARQUET-904) Define INT96 ordering
Julien Le Dem created PARQUET-904: - Summary: Define INT96 ordering Key: PARQUET-904 URL: https://issues.apache.org/jira/browse/PARQUET-904 Project: Parquet Issue Type: Improvement Components: parquet-format Reporter: Julien Le Dem Currently int96 binary ordering doesn't match its natural ordering. We should either specify this or declare int96 not ordered and link to the type replacing it. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (PARQUET-323) INT96 should be marked as deprecated
[
https://issues.apache.org/jira/browse/PARQUET-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julien Le Dem updated PARQUET-323:
--
Description:
As discussed in the mailing list, {{INT96}} is only used to represent nanosec
timestamp in Impala for some historical reasons, and should be deprecated.
Since nanosec precision is rarely a real requirement, one possible and simple
solution would be replacing {{INT96}} with {{INT64 (TIMESTAMP_MILLIS)}} or
{{INT64 (TIMESTAMP_MICROS)}}.
Several projects (Impala, Hive, Spark, ...) support INT96.
We need a clear spec of the replacement and the path to deprecation.
was:As discussed in the mailing list, {{INT96}} is only used to represent
nanosec timestamp in Impala for some historical reasons, and should be
deprecated. Since nanosec precision is rarely a real requirement, one possible
and simple solution would be replacing {{INT96}} with {{INT64
(TIMESTAMP_MILLIS)}} or {{INT64 (TIMESTAMP_MICROS)}}.
> INT96 should be marked as deprecated
>
>
> Key: PARQUET-323
> URL: https://issues.apache.org/jira/browse/PARQUET-323
> Project: Parquet
> Issue Type: Bug
> Components: parquet-format
>Reporter: Cheng Lian
>
> As discussed in the mailing list, {{INT96}} is only used to represent nanosec
> timestamp in Impala for some historical reasons, and should be deprecated.
> Since nanosec precision is rarely a real requirement, one possible and simple
> solution would be replacing {{INT96}} with {{INT64 (TIMESTAMP_MILLIS)}} or
> {{INT64 (TIMESTAMP_MICROS)}}.
> Several projects (Impala, Hive, Spark, ...) support INT96.
> We need a clear spec of the replacement and the path to deprecation.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (PARQUET-890) C++: Support I/O of DATE columns in parquet_arrow
[ https://issues.apache.org/jira/browse/PARQUET-890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15897158#comment-15897158 ] Uwe L. Korn commented on PARQUET-890: - PR: https://github.com/apache/parquet-cpp/pull/266 > C++: Support I/O of DATE columns in parquet_arrow > - > > Key: PARQUET-890 > URL: https://issues.apache.org/jira/browse/PARQUET-890 > Project: Parquet > Issue Type: New Feature > Components: parquet-cpp >Reporter: Uwe L. Korn >Assignee: Uwe L. Korn > > Currently we can only write Timestamp columns but no DATE columns to/from > Arrow. This did not occur earlier as the Pandas<->Parquet tests never pass > actuall date columns but Timestamp columns to Parquet. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
