Top priority is to "be like everyone else" since the whole point of SQL is that a lot of people are familiar with it. If everyone were doing the syntax, I would go with it even though adding syntax is a needless burden. But since major players are going with the function style, I prefer we do that.
BTW both BigQuery and Databricks support named parameters for functions. If those can be used with CHANGES, it greatly improves readability: CHANGES(cat.db.table, start_version => 123, end_version => 456) CHANGES(cat.db.table, start_timestamp => '2026-10-01', end_timestamp => '2026-10-22') Kenn On Mon, Oct 12, 2026 at 5:35 PM Reuven Lax via dev <[email protected]> wrote: > In terms of readability, they are similar. I prefer the table-function as > it minimizes the addition of new, non-standard SQL syntax. It's also > implicitly compatible with any future SQL syntax that is standardized for > changestreams, as we can rewrite the table function to expand to this new > syntax. > > On Mon, Oct 12, 2026 at 2:13 PM Ahmed Abualsaud via dev < > [email protected]> wrote: > >> Hey everyone, >> >> Surfacing a question raised from the doc regarding how users should ask >> for a table's changelog. I'd like more input before building it. >> >> *Option 1*: a clause after the table name (similar to Spark, Snowflake) >> >> SELECT * FROM cat.db.table *CHANGES* FROM VERSION 123 TO VERSION 456; >> SELECT * FROM cat.db.table *CHANGES* FROM TIMESTAMP '2026-10-01' TO >> TIMESTAMP >> '2026-10-12'; >> >> *Option 2*: a table function (similar to BigQuery, Databricks) >> >> SELECT * FROM *CHANGES(*cat.db.table, 123, 456*);* >> SELECT * FROM *CHANGES(*cat.db.table, '2026-10-01', '2026-10-12'*);* >> >> Which syntax would you prefer, and why? More examples are in the doc >> <https://docs.google.com/document/d/1k_RBQmSvf0H5ZayRf2E_oUK1HpcBwryiJBH5BJv2mwA/edit?tab=t.0> >> if >> that helps. >> >> >> On Wed, Oct 7, 2026 at 1:30 PM Ahmed Abualsaud <[email protected]> >> wrote: >> >>> Hey everyone, >>> >>> >>> I'd like to propose two additions to how Beam SQL refers to a table: >>> >>> 1. *CHANGES*, to read a table's row-level changes instead of its >>> current contents: >>> >>> SELECT * FROM cat.db.orders CHANGES FROM VERSION 1 TO VERSION 5 >>> >>> 2. *WITH*, to set connector options for one query: >>> >>> INSERT INTO cat.db.events WITH ('distribution_mode' = 'hash') SELECT >>> ... >>> >>> Both follow Spark SQL's syntax (SPARK-55948 >>> <https://issues.apache.org/jira/browse/SPARK-55948> and SPARK-36680 >>> <https://issues.apache.org/jira/browse/SPARK-36680>) and would improve >>> ease of use. >>> >>> More details and example usage in the doc. Comments and suggestions are >>> welcome! >>> >>> >>> >>> https://docs.google.com/document/d/1k_RBQmSvf0H5ZayRf2E_oUK1HpcBwryiJBH5BJv2mwA/edit >>> >>> Thanks, >>> >>> Ahmed >>> >>>
