I feel like if we want to support updating/adding a representation for a specific engine, the right way is to allow 'ALTER VIEW' to update or add the current engine's representation.
I don't think we can expect an engine to add or update other engines' representations because that would potentially require parsing a different SQL syntax than is native to the engine. For the example you gave where there's an existing representation in Trino, then using `ALTER VIEW . . .` would just set the spark representation (as opposed to a `REPLACE` or `CREATE` that would create a new representation with only the spake dialect). I don't like the idea of adding properties to toggle behavior though as that makes something declarative subject to side-effects of the configuration/session. -Dan On Fri, Sep 4, 2026 at 3:37 PM Alex Stephen via dev <[email protected]> wrote: > I'm not sure if `CREATE VIEW` would be the correct choice, as much as > `ALTER VIEW`. The user can see that a view exists through `SHOW VIEWS` > (which just calls the underlying List Views API), so they know that they > don't need to create a view as much as alter it. > > The Java implementation > <https://github.com/apache/iceberg/blob/main/core/src/main/java/org/apache/iceberg/view/BaseView.java#L114-L130> > surfaces > the first representation when a matching one doesn't exist. This assumes > representations are more-or-less compatible between engines, which isn't > the case. > > I'm concerned about the user journey where a user attempts to query a view > and receives an error message stating they cannot query it due to a wrong > engine or invalid SQL syntax (because their engine is using the wrong > representation). At this point, their only current recourse is to use the > REST endpoints directly to add their new representation. > > On Fri, Sep 4, 2026 at 3:01 PM Ryan Blue <[email protected]> wrote: > >> I think the intent was for this to happen through API integration. What >> is the user interaction that you're trying to achieve? Do you want each >> `CREATE VIEW` call to automatically append a new representation? >> >> On Fri, Sep 4, 2026 at 2:32 PM Alex Stephen via dev < >> [email protected]> wrote: >> >>> Hello, >>> >>> The view spec allows creating a single view with multiple >>> engine-specific representations. This allows a single view to be queried by >>> multiple engines, each using its own specific SQL dialect. >>> >>> In practice, this is difficult to achieve. Users can use the >>> `replace.drop-dialect.allowed` view property to allow the replacing of an >>> existing representation. However, there's no way to append a representation >>> (by creating a new ViewVersion with the existing representations and a new >>> one). This means that a direct REST API call is the only way to create a >>> View with multiple representations. >>> >>> I'd like to propose the creation of a new view property called >>> `replace.append-dialect.allowed` that allows users to append a new >>> representation to an existing view. >>> >>> PR: https://github.com/apache/iceberg/pull/17930 >>> >>> Please take a look. I'd love to hear from the community whether there is >>> value in this use case. >>> >>> Thanks! >>> >>> -- Alex Stephen >>> >>
