Seems clearly useful. Just to derail the thread... :-) what is the eventual endpoint of the Beam SQL DDL work like this? It seems like we are probably duplicating something that has been done many times before. Namely: having a model of what a table is, and a way to map DDL to specific implementations that have different backing connectors.
I think it still makes sense to have our SQL CLI / driver or other things built on Beam SQL be able to "do it all" because it is a whole-product entrypoint. And of course many many sibling projects have their own full implementation of all this stuff. Is there a way we can do this "all at once" and be done with it, having the whole "you type SQL into Beam and we know how to do the thing to the underlying storage / catalog" step? It feels like we shouldn't need many designs or discussion around it, unless it has Beam-specific considerations, and we could possibly crank it out semi-automatically? Or TBH integrating with something is better than vibe coding, so as to get maintenance and improvements for free. Kenn On Thu, Oct 22, 2026 at 11:33 PM Ahmed Abualsaud via dev < [email protected]> wrote: > Hey everyone, > > Following up on the last proposal, this one allows users to create a table > with a Primary Key or modify an existing table's Primary Key using Beam SQL. > > > https://docs.google.com/document/d/1lGynrfHlyvcmmyzJZ2gkL9zK8KF1ZnfkcImnMmM_ciw/edit > > This is a necessary piece to facilitate using CDC in Beam SQL. Looking > for feedback and suggestions! > > Best, > Ahmed >
