liurenjie1024 commented on issue #159:
URL: https://github.com/apache/iceberg-rust/issues/159#issuecomment-1890430482
> I don't think the BoundExpression is something that a user would ever use
as it is internal.
>
> let literal = BoundLiteral::builder.with_literal(...).build();
>
Fokko commented on issue #159:
URL: https://github.com/apache/iceberg-rust/issues/159#issuecomment-1889992180
> 2. The parse string method implemented in pyiceberg is not a typical
approach in rust. Rust has elegant support for macros, which is efficient and
type safe.
This was more
liurenjie1024 commented on issue #159:
URL: https://github.com/apache/iceberg-rust/issues/159#issuecomment-1888570500
> Does this proposal look like following?
>
> let literal = BoundLiteral::builder.with_literal(...).build();
> TableScan scan = scan.filter(Expressions.equal("id", l
ZENOTME commented on issue #159:
URL: https://github.com/apache/iceberg-rust/issues/159#issuecomment-1888563964
>When user construction UnboundExpression, it's not always from sql. For
example when we integrate it with other sql engines, it may push filter to
iceberg api to construct Unboun
liurenjie1024 commented on issue #159:
URL: https://github.com/apache/iceberg-rust/issues/159#issuecomment-1888538588
I think we have reached consensus that storing a `BoundLiteral` in
`UnboundExpression` is acceptable. About the visibility of this struct, I would
argue that we still need t
Fokko commented on issue #159:
URL: https://github.com/apache/iceberg-rust/issues/159#issuecomment-1887912820
First of all, thanks for the explanation of the Literal.
> This sounds a good idea to me, which doesn't introduce extra maintain
effort. The only concern is that it maybe not
liurenjie1024 commented on issue #159:
URL: https://github.com/apache/iceberg-rust/issues/159#issuecomment-1886064501
> @liurenjie1024 mentioned error messages as another use cases. That's the
only time that the i128 representation might not be suitable. The question is
whether the error me
JanKaul commented on issue #159:
URL: https://github.com/apache/iceberg-rust/issues/159#issuecomment-1884586498
Following @Fokko's reasoning, Decimal is comparable to TimestampZ where the
timezone is stored in the type. Similarly the scale of the Decimal is stored in
the type.
I thin
liurenjie1024 commented on issue #159:
URL: https://github.com/apache/iceberg-rust/issues/159#issuecomment-1884133592
> What do you mean by self-contained? For example, why is a date
self-contained, and a decimal not?
Sorry for the unclear description. Currently the decimal value is s
Fokko commented on issue #159:
URL: https://github.com/apache/iceberg-rust/issues/159#issuecomment-188878
> Sometimes it's self contained, for simple types such as int, date, string.
> Sometimes it's not self contained, for example decimal.
What do you mean by self-contained? Fo
ZENOTME commented on issue #159:
URL: https://github.com/apache/iceberg-rust/issues/159#issuecomment-1882940112
> Add a new type Datum which is self contained primitive value, it can be
implemented as following
This idea looks good to me. But I'm concerned about the conversion effort
liurenjie1024 commented on issue #159:
URL: https://github.com/apache/iceberg-rust/issues/159#issuecomment-1882841036
cc @Xuanwo @JanKaul @Fokko @ZENOTME
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above
liurenjie1024 opened a new issue, #159:
URL: https://github.com/apache/iceberg-rust/issues/159
In our discussion in #77, we decoupled type info from struct values. I'm
also facing some challenge when implementing #153. In short, the
`PrimitiveLiteral` is kind of weird:
1. Sometimes i
13 matches
Mail list logo
