emkornfield commented on code in PR #7504:
URL: https://github.com/apache/iceberg/pull/7504#discussion_r1184122115


##########
format/view-spec.md:
##########
@@ -111,12 +111,13 @@ The SQL representation stores the view definition as a 
SQL SELECT, with metadata
 |-------------|---------------------|----------------|-------------|
 | _required_  | `type`              | `string`       | Must be `sql` |
 | _required_  | `sql`               | `string`       | A SQL SELECT statement |
-| _required_  | `dialect`           | `string`       | The dialect of the 
`sql` SELECT statement (e.g., "trino" or "spark") |
+| _required_  | `dialect`           | `string`       | The dialect of the 
`sql` SELECT statement (e.g., "trino" or "spark"). Unless a version is provided 
only one view definition for each `type` and `dialect` should be present in a 
view definition.  |

Review Comment:
   I'm OK removing this.  It is possible I was misunderstanding this sentence:
   
   > Each representation is an object with at least one common field, `type`, 
that is one of the following:
   > `sql`: a SQL SELECT statement that defines the view
   
   I thought the intent was to support multiple dialects, for the same type, 
but maybe the intent here is to say "type" is the unique key here? Which raises 
the question should dialect be required? It seems like a nice to have for 
compatibility reasons?
   
   > If additions are not supported, then the SQL will fail to be parsed or 
analyzed. We would not want to reject a dialect if it is a newer version 
because that would prevent using many SQL queries that are compatible with 
older versions.
   
   I think the use-case here would be migrations for the cases where changes 
are breaking?



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to