Thanks for starting the thread Alex,
I agree with Dan, an engine should only update / add their own dialect and
not make guarantees about other engine dialects without passing through the
other engine's compiler.
I would recommend ALTER too, I know engines such as starrocks have came up
with grammar [1] to be more specific that one is adding / modifying the
dialect, given the dialect is of starrocks, that could be an option :
*ALTER VIEW [<catalog>.<database>.]<view_name>( <column_name> [,
<column_name>]){ ADD | MODIFY } DIALECT<query_statement>*
[1]
https://docs.starrocks.io/docs/data_source/catalog/iceberg/DDL/#alter-view-to-update-starrocks-dialect
Best,
Prashant Singh
On Fri, Sep 4, 2026 at 4:33 PM Daniel Weeks <[email protected]> wrote:
> 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
>>>>
>>>
