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

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. For the primary keys, what is the use case you're trying to solve? Do your tables allow null values in primary key

Re: two proposed spec changes

On Thu, Aug 24, 2023 at 5:28 PM Ryan Blue wrote: > I think it's a good idea to start adding timestamp types with nanosecond > precision. I've heard this a few times lately and having a column of nanos > as a work-around isn't a great solution. I'm much more skeptical that we > should allow millis

Re: two proposed spec changes

I think it's a good idea to start adding timestamp types with nanosecond precision. I've heard this a few times lately and having a column of nanos as a work-around isn't a great solution. I'm much more skeptical that we should allow millis though. That just introduces more for engines to implement

Re: two proposed spec changes

wrt 2) Agreed, NULL != NULL is standard. The human interpretation is NULL = "unknown". However, exceptions are not uncommon. - MySQL docs state "The NULL value means “no data.” ". - SQL Server accommodates (NULL = NULL) == TRUE via SET ANS

Re: two proposed spec changes

+1 for 1). For 2), I don’t think allowing optional field in identifier field would 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