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 <rb...@netflix.com.INVALID> wrote: > 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 the internal representation in Spark and Iceberg are the same. The > conversion from long to date was never really needed by this path, so we > probably didn't add it. Iceberg is fairly strict with allowed conversions > to date and timestamp because the validation we can apply is still very > permissive. > > I think it's fine to add long to date if there is a need, but otherwise I'd > leave it as it is. Do you have a use case for this? > > On Tue, Feb 18, 2020 at 3:19 PM Vlad Rozov <vro...@apache.org> wrote: > > > Hi, > > > > What is the reason iceberg does not allow LongLiteral to DateLiteral > > conversion while allowing LongLiteral to IntegerLiteral and IntegerLiteral > > to DateLiteral? Should not direct conversion from LongLiteral to > > DateLiteral be allowed when LongLiteral represents values in a proper range? > > > > Thank you, > > > > Vlad > > > > -- > Ryan Blue > Software Engineer > Netflix >
