+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 >
