Views: Clean up and clarify the view spec

[rdblue]

This cleans up and clarifies a few places in the view spec. It is formatted to be more like the table spec.

[rdblue]

@amogh-jahagirdar, this is currently field-comments in the implementation. Which one do you want to change?

[amogh-jahagirdar]

Good catch, I'd prefer to change the spec to be field-comments. My rationale is that most operations (at least via SQL) will actually explicitly refer to the word "comment" so it seems more natural.

for example CREATE VIEW v (alias_name COMMENT 'docs', alias_name2, ...) AS SELECT col1, col2, ...

[rdblue]

Updated. Please have another look and I'll commit when you +1.

[amogh-jahagirdar]

This looks good to me, thanks @rdblue !

[rdblue]

Thanks, @amogh-jahagirdar!

[wmoustafa]

I think it would be great to clarify a few things:

1- If we should document that version summary, namely engine and engine version, should have a correlation with the view dialect. For example, views created from Trino will typically be in Trino SQL.

2- If we should document whether a view version is immutable in terms of adding representations. Can an old (or committed) view version be changed to receive a new representation?

3- If we should document whether a view version can contain two definitions under the same type/dialect.

4- We discussed documenting possible values in the view interfaces PR. For example, similar to what we say that type must be sql, how about saying that dialect could be one of some options? This is just to avoid situations where there are dialects like spark, Spark, SparkSQL, spark3.3.

Happy to raise an issue or a community discussion around some of the above.

[rdblue]

Thanks for reviewing this, @wmoustafa.

1. I'm okay with this, but I don't think it is necessarily the case. Engines could support multiple dialects. Plus, I think it's pretty obvious that it will generally be true.
2. View versions are immutable once created.
3. Right now, there should not be duplicates for any representation type.
4. I'm okay doing this, but it doesn't seem worthwhile to me. There will typically be one implementation per engine and people aren't going to change this often.