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