AFAIK, Presto uses 4 bytes for DateType as well as for IntegerType for its
internal representation, but java signature is Long, so from an API point of
view, it is long. When Presto constructs iceberg Predicates using, for example,
equal(String name, T value), the actual parameter is of type Lon
I'm not quite following. What is the internal representation that Presto
uses for dates?
On Wed, Feb 19, 2020 at 12:58 PM Vlad Rozov wrote:
> While it is possible to convert to IntLiteral or even probably to
> DateLiteral, presto mostly delegates to iceberg to do the proper
> conversion from Lo
While it is possible to convert to IntLiteral or even probably to DateLiteral,
presto mostly delegates to iceberg to do the proper conversion from
LongLiteral, AFAIK (see
https://github.com/prestosql/presto/blob/de97d1572d7da5570177627bd42fbb8b7fdd417e/presto-iceberg/src/main/java/io/prestosql/
Can you describe the use case a bit more? What prevents you from using an
IntLiteral instead?
On Wed, Feb 19, 2020 at 11:26 AM Vlad Rozov wrote:
> Hi Ryan,
>
> Thank you for the detailed explanation. Yes, there is a use case in Presto
> for LongLiteral to DateLiteral conversion as it uses long a
Sounds fine to me. Can you open a PR for this?
On Wed, Feb 19, 2020 at 11:40 AM Vlad Rozov wrote:
> Hi Ryan,
>
> Currently, it is a cherry-pick of classes from org.apache.iceberg and few
> other packages likely based on minimizing existing static imports plus all
> tests being excluded from the
Regarding the Hive versions... from what I've seen over on the Hive mailing
lists it sounds like Spark 3.0 will be targeting Hive 2.3.x based on
whether they can get the Hive community to do a new point release of Hive
before they finalise Spark 3.0. So hopefully that gets sorted in time and
then I
Hi Ryan,
Currently, it is a cherry-pick of classes from org.apache.iceberg and few other
packages likely based on minimizing existing static imports plus all tests
being excluded from the avoid static import rule. I'd suggest removing all
exceptions from the rule and prohibiting static import f
Hi Ryan,
Thank you for the detailed explanation. Yes, there is a use case in Presto for
LongLiteral to DateLiteral conversion as it uses long and allows it to be
converted/cast to Date.
Thank you,
Vlad
On 2020/02/19 18:54:35, Ryan Blue wrote:
> Originally, we didn't allow int to date or lon
Hi Vlad,
What is the current rule? What do you think we should change it to and why
is that a good idea?
On Tue, Feb 18, 2020 at 3:54 PM Vlad Rozov wrote:
> Hi,
>
> Should static imports be prohibited for all packages or
> “org.apache.iceberg.*” should be excluded from the avoid static imports
Originally, we didn't allow int to date or long to timestamp, but we added
those to support expression conversion from Spark. It's much easier to
allow the LongLiteral created from a Spark timestamp expression directly to
a TimestampLiteral than to convert to an equivalent timestamp string
because
10 matches
Mail list logo
