en chatgpt fix

Author: jepett0

ydb/docs/en/core/concepts/datamodel/view.md

@@ -35,7 +35,7 @@ Queries are executed in 2 steps:
 1. compilation,
 2. execution of the compiled code.
 
-The resultant compiled code contains no evidence that the query was made using views, because all the references to views should have been replaced during compilation by the queries that they represent. It practice it means that there must be no difference in the execution time of the compiled code (step №2) for queries made using views vs. queries directly reading from the underlying tables.
+The resultant compiled code contains no evidence that the query was made using views, because all the references to views should have been replaced during compilation by the queries that they represent. In practice, it means that there must be no difference in the execution time of the compiled code (step №2) for queries made using views vs. queries directly reading from the underlying tables.
 
 However, users might notice a little increase in the compilation time of the queries made using views compared to the compilation time of the same queries written directly. It happens due to the fact that a statement reading from a view:
 ```sql
@@ -61,7 +61,7 @@ compilation results will be cached on the {{ ydb-short-name }} server and you wi
 ```sql
 SELECT 1;
 ```
-compilation can take up to a hundred times more CPU time than the execution. The cache entry is searched by the text of the query and some additional info such as a user SID.
+compilation can take up to a hundred times more CPU time than the execution. The cache entry is searched by the text of the query and some additional information such as a user SID.
 
 The cache is updated by {{ ydb-short-name }} automatically to stay on track with the changes made to the objects that the query references. However, in the case of views the cache is not updated in the same transaction in which the object's definition changes. It happens with a little delay.
 

ydb/docs/en/core/yql/reference/yql-core/syntax/alter_view.md

@@ -2,10 +2,10 @@
 
 ALTER VIEW — change the definition of a view.
 
-This feature is not supported yet. You can redefine a view like this:
+This feature is not supported yet. You can redefine a view by dropping it and recreating it with a different query or options values:
 ```sql
-DROP VIEW redifined_view;
-CREATE VIEW redifined_view ...;
+DROP VIEW redefined_view;
+CREATE VIEW redefined_view ...;
 ```
 
 ## See also

ydb/docs/en/core/yql/reference/yql-core/syntax/create_view.md

@@ -33,9 +33,17 @@ This option causes the underlying base relations to be checked against the privi
 
 `security_invoker` option must be always set to true, because the default behavior for views is to execute the query on behalf of the view's creator, which is not supported yet.
 
-The execution context of the view's query is different from the enclosing context of the SELECT from the view statement. It does not "see" previously defined PRAGMAs like TablePathPrefix, named expressions, etc. Most importantly, users must specify the tables (or views) they select from in the view's query by their schema-qualified names. You can see in the [examples](#examples) that the absolute path like `/domain/database/path/to/underlying_table` is used to specify the table, from which the view selects. We are going to change the context of the view's query compilation in the next releases.
+The execution context of the view's query is different from the context of the enclosing SELECT from the view statement. It does not "see" previously defined PRAGMAs like TablePathPrefix, named expressions, etc. Most importantly, users must specify the tables (or views) they select from in the view's query by their schema-qualified names. You can see in the [examples](#examples) that the absolute path like `/domain/database/path/to/underlying_table` is used to specify the table, from which a view selects. The particular context of the view's query compilation might change in next releases.
 
-The only way to specify the columns you want to see in the view is to select them in particular in the view's query. Star (\*) expansions in the view's query happens each time you recompile it. The columns returned by the following statement:
+If you wish to specify column names that you would like to see in the output of the view, you might do so by modifying the view's query:
+```sql
+CREATE VIEW view_with_a_renamed_column WITH (security_invoker = TRUE) AS
+    SELECT
+        original_column_name AS custom_column_name
+    FROM `/domain/database/path/to/underlying_table`;
+```
+
+Star (`*`) expansion in the view's query happens each time you read from the view. The list of columns returned by the following statement:
 ```sql
 /*
 CREATE VIEW view_with_a_star WITH (security_invoker = TRUE) AS
@@ -46,7 +54,7 @@ CREATE VIEW view_with_a_star WITH (security_invoker = TRUE) AS
 
 SELECT * FROM view_with_a_star;
 ```
-might change if the columns list of the `underlying_table` changes.
+will change if the list of columns of the `underlying_table` is altered.
 
 ## Examples {#examples}