wmoustafa commented on code in PR #7504:
URL: https://github.com/apache/iceberg/pull/7504#discussion_r1186644713
##########
format/view-spec.md:
##########
@@ -328,3 +330,17 @@
s3://bucket/warehouse/default.db/event_agg/metadata/00002-(uuid).metadata.json
} ]
}
```
+
+## Appendix B: Well Known (canonical) dialects
+
+The following dialects names are reserved and indicate dialects for specific
systems:
+
+| Dialect Name | Description
| Versioning |
+|--------------|-------------------------------------------------------------------------------------------------------|-------------|
+|athena | [Amazon Athena
Dialect](https://docs.aws.amazon.com/athena/latest/ug/ddl-sql-reference.html)
| TBD |
+|google_sql | [Google's SQL
Dialect](https://cloud.google.com/bigquery/docs/reference/standard-sql/query-syntax)
| TBD |
+|spark | [Apache Spark SQL
Dialect](https://spark.apache.org/docs/latest/sql-ref-ansi-compliance.html)
| TBD |
+|trino | [Trino SQL
Dialect](https://trino.io/docs/current/language.html)
| TBD |
+
+Dialect names starting with "iceberg." are reserved for future extension. Well
known dialects
+may be added in the future with the prefix of "iceberg." (E.g.
"iceberg.new_dialect_name").
Review Comment:
I see. My feedback is that defining a list of acceptable values, then
allowing the clients to choose other values while having the spec to adapt by
using the "iceberg." prefix sounds contradictory. Further, since it will be
hard to enumerate all custom values used in the clients, this means that future
dialects can only start with "iceberg.", which is a bit odd. This leaves us
with option (1) and the ".custom" version of option (2), where clients are the
ones who have to prefix by "custom.". I feel that the "custom." version, while
allowing some flexibility, still leaves a backdoor around what this spec is
trying achieve, and somewhat defeats the purpose. If we go with option (1),
clients can still use a custom dialect name, but at least be aware that it
might collide with the spec in the future (once extended), so such clients have
to actively promote the new dialect name to the spec if it is valid.
--
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]
