Also, view metadata versions and (underlying) table snapshots/versions are orthogonal concepts. For example, theoretically, one could time-travel in views along two dimensions: view metadata version and underlying data version. Hence, I do not think that data versioning in tables corresponds exactly to view metadata versioning. Instead of mapping/porting the feature from tables to views, we can approach this by discussing the use case we are trying to unlock with this proposal. Maybe there is a better way to support the use case.
Thanks, Walaa. On Mon, Nov 13, 2023 at 11:47 PM Ajantha Bhat <ajanthab...@gmail.com> wrote: > Hi Jan, > > In my view, branches are primarily intended for isolating tests and later > merging them back (commonly referred to as the WAP scenario). > Tags, conversely, serve the purpose of marking significant snapshots for > reproducibility or auditing. > > Views essentially act as a shorthand for queries. Creating or replacing a > view is a metadata operation with no data involvement. > So, branching and tagging support may be an overkill. > > However, when dealing with materialized views, it becomes crucial to > support branching and tagging, given that these operations involve data > manipulation. > > Thanks, > > Ajantha >
