Re: two proposed spec changes

There are a couple problems with default values. First, they are part of v3 and haven’t been implemented yet. But the second larger issue is that null is a value. A default doesn’t replace a null that was written in the data. I don’t think default values would help out here. What I meant by derive

Re: two proposed spec changes

Please define "derived field"? We don't allow empty string as a tag value, so that sentinel value is available. However, there are some second-order effects that need to be considered. Just thinking out loud, I haven't explored using default values for tags in our Iceberg export code; certainly n

Re: two proposed spec changes

Jacob, could you model this with a derived field? Or could you require the tags and use a "unknown" value? On Mon, Aug 28, 2023 at 11:18 AM Jacob Marble wrote: > On Fri, Aug 25, 2023 at 3:23 PM Ryan Blue wrote: > >> I don't think that we should introduce nanosecond precision types without >> at

Re: two proposed spec changes

On Fri, Aug 25, 2023 at 3:23 PM Ryan Blue wrote: > I don't think that we should introduce nanosecond precision types without > at least supporting both timestamp and timestamptz. I'm not sure whether > nanosecond time should be supported. > SGTM; this seems to be the most agreeable part of the p

Re: two proposed spec changes

Hi Jacob I agree with 1, it makes sense to use nanosecond precision. IMHO it should be available for both timestamp and timestamptz. For 2, I'm not sure. Let's see what the others think. Regards JB On Wed, Aug 23, 2023 at 10:17 PM Jacob Marble wrote: > > Good afternoon, > > I would like to pro

Re: two proposed spec changes

common interpretation. Indeed, a >>> query/compute engine may have its own reasons for handling primary >>> >>> On Wed, Aug 23, 2023 at 7:57 PM Renjie Liu >>> wrote: >>> >>>> +1 for 1). >>>> >>>> >>>&

Re: two proposed spec changes

t;>> be a good idea. If I understand correctly, identifier fields is quite >>> similar to primary key in relation database. In standard sql standard, NULL >>> != NULL. If optional field is allowed, then two rows (1, NULL), (1, NULL) >>> have exactly same value while the

Re: two proposed spec changes

L >> != NULL. If optional field is allowed, then two rows (1, NULL), (1, NULL) >> have exactly same value while they are not equal. The reason why float, >> double can’t be contained in primary key is similar. >> >> >> >> *From: *Jacob Marble >> *Da

Re: two proposed spec changes

in primary key is similar. > > > > *From: *Jacob Marble > *Date: *Thursday, August 24, 2023 at 04:18 > *To: *dev@iceberg.apache.org > *Subject: *two proposed spec changes > > Good afternoon, > > > > I would like to propose two changes to the Iceberg spec

Re: two proposed spec changes

), (1, NULL) have exactly same value while they are not equal. The reason why float, double can’t be contained in primary key is similar. From: Jacob Marble Date: Thursday, August 24, 2023 at 04:18 To: dev@iceberg.apache.org Subject: two proposed spec changes Good afternoon, I would like to

two proposed spec changes

Good afternoon, I would like to propose two changes to the Iceberg spec: 1) * Primitive types time, timestamp, timestamptz gain property "precision",* with three possible values: millis, micros, nanos (borrowing the list from Parquet