Re: Making the NDV property required for theta sketch blobs in Puffin

Hi Amogh +1 to have ndv blob metadata property required. As discussed during the last community meeting, we discussed voting on all code modification changes on spec. For the next spec changes, I would propose to start a voting thread, like "[VOTE][Puffin Spec] Make the ndv blob metadata property

Re: Making the NDV property required for theta sketch blobs in Puffin

I also support making this field required. Thanks, Nick Riasanovsky On Fri, Jun 21, 2024 at 7:00 PM Szehon Ho wrote: > It makes sense to me, normally changing optional -> required would > probably require a version bump, but maybe it is ok here as it is a > relatively new format, afaik adapted

Re: Making the NDV property required for theta sketch blobs in Puffin

It makes sense to me, normally changing optional -> required would probably require a version bump, but maybe it is ok here as it is a relatively new format, afaik adapted by Trino which already sets this field, but let's see if anyone disagrees. Thanks Szehon On Fri, Jun 21, 2024 at 3:35 PM huax

Re: Making the NDV property required for theta sketch blobs in Puffin

+1 for making the ndv blob metadata property required for theta sketches. On Fri, Jun 21, 2024 at 2:54 PM Amogh Jahagirdar <2am...@gmail.com> wrote: > Hey all, > > I wanted to raise this thread to discuss a spec change proposal > for making the ndv b

Making the NDV property required for theta sketch blobs in Puffin

Hey all, I wanted to raise this thread to discuss a spec change proposal for making the ndv blob metadata property required for theta sketches. Currently, the spec is a bit loose stating: The blob metadata for this blob *may* include following proper

Re: [DISCUSS] Describing REST Server capabilities

Let's remove the oauth2 tag for now until we figure out how to move forward there. That makes sense to me. On Fri, Jun 21, 2024 at 9:30 AM Dmitri Bourlatchkov wrote: > Hi Eduard, > > The capabilities PR looks good to me overall. I have a concern with the > "oauth2" tag name though. > > I also co

Re: [DISCUSS] Describing REST Server capabilities

Hi Eduard, The capabilities PR looks good to me overall. I have a concern with the "oauth2" tag name though. I also commented [1] in GH but the comment appears to be closed by default :) I believe the term "oauth2" is confusing in this context with respect to RFC 6749 [2] as discussed in depth o

Re: Iceberg MV Refresh

Hi Dan, looks like it is pretty common across engines and sometimes part of the engine specific DDL operation to create the MV. So, I agree let's keep the "*materialization.max-staleness*" property. I'll also point out that when the clock starts for this max staleness check could be either when t

Re: [DISCUSS] Describing REST Server capabilities

Hi Ryan, I think I wasn't clear (sorry about that): by "catalog-level-versioning" capability, I don't mean to actually define any specific version, it's more to indicate to the client how the catalog behaving in terms of versioning (per table/views or global to catalog). It's a "pure" capability i

Re: Iceberg MV Refresh

Benny, I think you bring up a good point about staleness in that different clients may want different behaviors. However, defining a "grace period" or "max staleness" is pretty common and makes a lot of sense when working with expensive queries. Trino