Hi all, I think option A is the best suggestion out of these. It's semantically accurate and aligns with established database and SQL terminology.
Best regards, Martijn On Fri, Jun 20, 2025 at 2:15 PM Arvid Heise <ar...@apache.org> wrote: > I'm also in favor of Option A of the presented options. > > I had one additional idea (Option F) that mixes two approaches B+E > > ROW_WISE_TABLE > SET_PARTITIONED_TABLE > > You'd have ROW and SET that comes from the SQL standard but you also have a > stronger connection between SET and partitioning. > > Best, > > Arvid > > On Fri, Jun 20, 2025 at 3:01 AM Hao Li <h...@confluent.io.invalid> wrote: > > > +1 for option A. It's consistent with calcite naming. > > > > On Thu, Jun 19, 2025 at 11:38 AM Sergey Nuyanzin <snuyan...@gmail.com> > > wrote: > > > > > Thanks for raising this > > > +1 for option A > > > > > > On Thu, Jun 19, 2025 at 4:05 PM Gustavo de Morais > > > <gustavopg...@gmail.com> wrote: > > > > > > > > Hi Timo, > > > > > > > > +1 (non-binding) for option A. Thanks for trying to address feedback > > > > quickly. > > > > > > > > Kind regards, > > > > Gustavo de Morais > > > > > > > > On Thu, 19 Jun 2025 at 15:51, Timo Walther <twal...@apache.org> > wrote: > > > > > > > > > Hi everyone, > > > > > > > > > > I'm currently polishing FLIP-440, I would like to apply some last > > > minute > > > > > changes before the first release of PTFs for Flink 2.1. I've > already > > > > > collected initial user feedback and it seems that the name for > > > > > annotations of table arguments is not precise enough. > > > > > > > > > > As always, naming is a hard problem in software engineering. > > > > > > > > > > For background, please take a look at this docs section: > > > > > > > > > > > > > > > > > > > > > https://nightlies.apache.org/flink/flink-docs-master/docs/dev/table/functions/ptfs/#table-semantics-and-virtual-processors > > > > > > > > > > Currently, a PTF signature can look like when taking a table as an > > > > > argument: > > > > > > > > > > // Untyped with set semantics > > > > > eval(@ArgumentHint(TABLE_AS_SET) Row order); > > > > > > > > > > // Typed with set semantics > > > > > eval(@ArgumentHint(TABLE_AS_SET) Order order); > > > > > > > > > > // Untyped with row semantics > > > > > eval(@ArgumentHint(TABLE_AS_ROW) Row order); > > > > > > > > > > // Typed with row semantics > > > > > eval(@ArgumentHint(TABLE_AS_ROW) Order order); > > > > > > > > > > The annotation value confuses people, so I would ask for renaming > > this > > > > > part of the API. > > > > > > > > > > Option A: > > > > > ROW_SEMANTIC_TABLE > > > > > SET_SEMANTIC_TABLE > > > > > > > > > > Option B: > > > > > ROW_WISE_TABLE > > > > > SET_WISE_TABLE > > > > > > > > > > Option C: > > > > > ROW_SCOPED_TABLE > > > > > SET_SCOPED_TABLE > > > > > > > > > > Option D: > > > > > KEYED_TABLE > > > > > UNKEYED_TABLE > > > > > > > > > > Option E: > > > > > PARTITIONED_TABLE > > > > > ROW_WISE_TABLE > > > > > > > > > > Option A/B/C are closer to SQL standard and not too far away from > > > > > current docs. Option D is closer to Flink DataStream API but could > be > > > > > confusing if no PARTITION BY clause is given but still the table > > could > > > > > be keyed. Option E neither takes SQL standard nor DataStream API > as a > > > > > reference. > > > > > > > > > > Personally, I would vote for Option A. > > > > > > > > > > Looking forward to your opinion. > > > > > > > > > > Cheers, > > > > > Timo > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Best regards, > > > Sergey > > > > > >
