Merge pull request #26973 from ClickHouse/docs-remove-trailing-whites…

…paces

Remove trailing whitespaces from docs

docs/README.md

@@ -9,7 +9,7 @@ Many developers can say that the code is the best docs by itself, and they are r
 If you want to help ClickHouse with documentation you can face, for example, the following questions:
 
 - "I don't know how to write."
-    
+
     We have prepared some [recommendations](#what-to-write) for you.
 
 - "I know what I want to write, but I don't know how to contribute to docs."
@@ -71,17 +71,17 @@ Contribute all new information in English language. Other languages are translat
     ```
 
 - Bold text: `**asterisks**` or `__underlines__`.
-- Links: `[link text](uri)`. Examples: 
+- Links: `[link text](uri)`. Examples:
 
     - External link: `[ClickHouse repo](https://github.com/ClickHouse/ClickHouse)`
     - Cross link: `[How to build docs](tools/README.md)`
 
 - Images: `![Exclamation sign](uri)`. You can refer to local images as well as remote in internet.
 - Lists: Lists can be of two types:
-    
+
     - `- unordered`: Each item starts from the `-`.
     - `1. ordered`: Each item starts from the number.
-    
+
     A list must be separated from the text by an empty line. Nested lists must be indented with 4 spaces.
 
 - Inline code: `` `in backticks` ``.
@@ -107,7 +107,7 @@ Contribute all new information in English language. Other languages are translat
 - Text hidden behind a cut (single sting that opens on click):
 
     ```text
-    <details markdown="1"> <summary>Visible text</summary> 
+    <details markdown="1"> <summary>Visible text</summary>
         Hidden content.
     </details>`.
     ```

docs/_description_templates/template-data-type.md

@@ -1,6 +1,6 @@
 ---
-toc_priority: 
-toc_title: 
+toc_priority:
+toc_title:
 ---
 
 # data_type_name {#data_type-name}

docs/_description_templates/template-engine.md

@@ -58,6 +58,6 @@ Result:
 
 Follow up with any text to clarify the example.
 
-**See Also** 
+**See Also**
 
 -   [link](#)

docs/_description_templates/template-function.md

@@ -14,16 +14,16 @@ More text (Optional).
 
 **Arguments** (Optional)
 
--   `x` — Description. Optional (only for optional arguments). Possible values: <values list>. Default value: <value>. [Type name](relative/path/to/type/dscr.md#type). 
--   `y` — Description. Optional (only for optional arguments). Possible values: <values list>.Default value: <value>. [Type name](relative/path/to/type/dscr.md#type). 
+-   `x` — Description. Optional (only for optional arguments). Possible values: <values list>. Default value: <value>. [Type name](relative/path/to/type/dscr.md#type).
+-   `y` — Description. Optional (only for optional arguments). Possible values: <values list>.Default value: <value>. [Type name](relative/path/to/type/dscr.md#type).
 
 **Parameters** (Optional, only for parametric aggregate functions)
 
 -   `z` — Description. Optional (only for optional parameters). Possible values: <values list>. Default value: <value>. [Type name](relative/path/to/type/dscr.md#type).
 
 **Returned value(s)**
 
--   Returned values list. 
+-   Returned values list.
 
 Type: [Type name](relative/path/to/type/dscr.md#type).
 

docs/_includes/cmake_in_clickhouse_footer.md

@@ -16,8 +16,8 @@ Better:
 option(ENABLE_TESTS "Provide unit_test_dbms target with Google.test unit tests" OFF)
 ```
 
-If the option's purpose can't be guessed by its name, or the purpose guess may be misleading, or option has some 
-pre-conditions, leave a comment above the `option()` line and explain what it does. 
+If the option's purpose can't be guessed by its name, or the purpose guess may be misleading, or option has some
+pre-conditions, leave a comment above the `option()` line and explain what it does.
 The best way would be linking the docs page (if it exists).
 The comment is parsed into a separate column (see below).
 
@@ -33,7 +33,7 @@ option(ENABLE_TESTS "Provide unit_test_dbms target with Google.test unit tests"
 
 Suppose you have an option that may strip debug symbols from the ClickHouse's part.
 This can speed up the linking process, but produces a binary that cannot be debugged.
-In that case, prefer explicitly raising a warning telling the developer that he may be doing something wrong. 
+In that case, prefer explicitly raising a warning telling the developer that he may be doing something wrong.
 Also, such options should be disabled if applies.
 
 Bad:

docs/en/commercial/support.md

@@ -7,7 +7,7 @@ toc_title: Support
 
 !!! info "Info"
     If you have launched a ClickHouse commercial support service, feel free to [open a pull-request](https://github.com/ClickHouse/ClickHouse/edit/master/docs/en/commercial/support.md) adding it to the following list.
-    
+
 ## Yandex.Cloud
 
 ClickHouse worldwide support from the authors of ClickHouse. Supports on-premise and cloud deployments. Ask details on clickhouse-support@yandex-team.com

docs/en/development/adding_test_queries.md

@@ -4,11 +4,11 @@ ClickHouse has hundreds (or even thousands) of features. Every commit gets check
 
 The core functionality is very well tested, but some corner-cases and different combinations of features can be uncovered with ClickHouse CI.
 
-Most of the bugs/regressions we see happen in that 'grey area' where test coverage is poor. 
+Most of the bugs/regressions we see happen in that 'grey area' where test coverage is poor.
 
-And we are very interested in covering most of the possible scenarios and feature combinations used in real life by tests. 
+And we are very interested in covering most of the possible scenarios and feature combinations used in real life by tests.
 
-## Why adding tests 
+## Why adding tests
 
 Why/when you should add a test case into ClickHouse code:
 1) you use some complicated scenarios / feature combinations / you have some corner case which is probably not widely used
@@ -17,18 +17,18 @@ Why/when you should add a test case into ClickHouse code:
 4) once the test is added/accepted, you can be sure the corner case you check will never be accidentally broken.
 5) you will be a part of great open-source community
 6) your name will be visible in the `system.contributors` table!
-7) you will make a world bit better :) 
+7) you will make a world bit better :)
 
 ### Steps to do
 
-#### Prerequisite 
+#### Prerequisite
 
-I assume you run some Linux machine (you can use docker / virtual machines on other OS) and any modern browser / internet connection, and you have some basic Linux & SQL skills. 
+I assume you run some Linux machine (you can use docker / virtual machines on other OS) and any modern browser / internet connection, and you have some basic Linux & SQL skills.
 
 Any highly specialized knowledge is not needed (so you don't need to know C++ or know something about how ClickHouse CI works).
 
 
-#### Preparation 
+#### Preparation
 
 1) [create GitHub account](https://github.com/join) (if you haven't one yet)
 2) [setup git](https://docs.github.com/en/free-pro-team@latest/github/getting-started-with-github/set-up-git)
@@ -54,17 +54,17 @@ git remote add upstream https://github.com/ClickHouse/ClickHouse
 
 #### New branch for the test
 
-1) create a new branch from the latest clickhouse master 
+1) create a new branch from the latest clickhouse master
 ```
 cd ~/workspace/ClickHouse
 git fetch upstream
-git checkout -b name_for_a_branch_with_my_test upstream/master 
+git checkout -b name_for_a_branch_with_my_test upstream/master
 ```
 
-#### Install & run clickhouse 
+#### Install & run clickhouse
 
 1) install `clickhouse-server` (follow [official docs](https://clickhouse.tech/docs/en/getting-started/install/))
-2) install test configurations (it will use Zookeeper mock implementation and adjust some settings) 
+2) install test configurations (it will use Zookeeper mock implementation and adjust some settings)
 ```
 cd ~/workspace/ClickHouse/tests/config
 sudo ./install.sh
@@ -74,7 +74,7 @@ sudo ./install.sh
 sudo systemctl restart clickhouse-server
 ```
 
-#### Creating the test file 
+#### Creating the test file
 
 
 1) find the number for your test - find the file with the biggest number in `tests/queries/0_stateless/`
@@ -86,7 +86,7 @@ tests/queries/0_stateless/01520_client_print_query_id.reference
 ```
 Currently, the last number for the test is `01520`, so my test will have the number `01521`
 
-2) create an SQL file with the next number and name of the feature you test 
+2) create an SQL file with the next number and name of the feature you test
 
 ```sh
 touch tests/queries/0_stateless/01521_dummy_test.sql
@@ -112,16 +112,16 @@ clickhouse-client -nmT < tests/queries/0_stateless/01521_dummy_test.sql | tee te
 	- fast - should not take longer than a few seconds (better subseconds)
 	- correct - fails then feature is not working
         - deterministic
-	- isolated / stateless 
+	- isolated / stateless
 		- don't rely on some environment things
-		- don't rely on timing when possible 
-- try to cover corner cases (zeros / Nulls / empty sets / throwing exceptions) 
+		- don't rely on timing when possible
+- try to cover corner cases (zeros / Nulls / empty sets / throwing exceptions)
 - to test that query return errors, you can put special comment after the query: `-- { serverError 60 }` or `-- { clientError 20 }`
 - don't switch databases (unless necessary)
 - you can create several table replicas on the same node if needed
 - you can use one of the test cluster definitions when needed (see system.clusters)
 - use `number` / `numbers_mt` / `zeros` / `zeros_mt` and similar for queries / to initialize data when applicable
-- clean up the created objects after test and before the test (DROP IF EXISTS) - in case of some dirty state 
+- clean up the created objects after test and before the test (DROP IF EXISTS) - in case of some dirty state
 - prefer sync mode of operations (mutations, merges, etc.)
 - use other SQL files in the `0_stateless` folder as an example
 - ensure the feature / feature combination you want to test is not yet covered with existing tests
@@ -138,7 +138,7 @@ It's important to name tests correctly, so one could turn some tests subset off
 
 #### Commit / push / create PR.
 
-1) commit & push your changes 
+1) commit & push your changes
 ```sh
 cd ~/workspace/ClickHouse
 git add tests/queries/0_stateless/01521_dummy_test.sql
@@ -147,5 +147,5 @@ git commit # use some nice commit message when possible
 git push origin HEAD
 ```
 2) use a link which was shown during the push, to create a PR into the main repo
-3) adjust the PR title and contents, in `Changelog category (leave one)` keep 
-`Build/Testing/Packaging Improvement`, fill the rest of the fields if you want. 
+3) adjust the PR title and contents, in `Changelog category (leave one)` keep
+`Build/Testing/Packaging Improvement`, fill the rest of the fields if you want.

docs/en/engines/database-engines/atomic.md

@@ -17,7 +17,7 @@ It supports non-blocking [DROP TABLE](#drop-detach-table) and [RENAME TABLE](#re
 
 ### Table UUID {#table-uuid}
 
-All tables in database `Atomic` have persistent [UUID](../../sql-reference/data-types/uuid.md) and store data in directory `/clickhouse_path/store/xxx/xxxyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy/`, where `xxxyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy` is UUID of the table. 
+All tables in database `Atomic` have persistent [UUID](../../sql-reference/data-types/uuid.md) and store data in directory `/clickhouse_path/store/xxx/xxxyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy/`, where `xxxyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy` is UUID of the table.
 Usually, the UUID is generated automatically, but the user can also explicitly specify the UUID in the same way when creating the table (this is not recommended). To display the `SHOW CREATE` query with the UUID you can use setting [show_table_uuid_in_table_create_query_if_not_nil](../../operations/settings/settings.md#show_table_uuid_in_table_create_query_if_not_nil). For example:
 
 ```sql

docs/en/engines/database-engines/materialized-mysql.md

@@ -36,8 +36,8 @@ ENGINE = MaterializedMySQL('host:port', ['database' | database], 'user', 'passwo
 -   `max_wait_time_when_mysql_unavailable` — Retry interval when MySQL is not available (milliseconds). Negative value disable retry. Default: `1000`.
 -   `allows_query_when_mysql_lost` — Allow query materialized table when mysql is lost. Default: `0` (`false`).
 ```
-CREATE DATABASE mysql ENGINE = MaterializedMySQL('localhost:3306', 'db', 'user', '***') 
-     SETTINGS 
+CREATE DATABASE mysql ENGINE = MaterializedMySQL('localhost:3306', 'db', 'user', '***')
+     SETTINGS
         allows_query_when_mysql_lost=true,
         max_wait_time_when_mysql_unavailable=10000;
 ```
@@ -52,10 +52,10 @@ For the correct work of `MaterializeMySQL`, there are few mandatory `MySQL`-side
 ## Virtual columns {#virtual-columns}
 
 When working with the `MaterializedMySQL` database engine, [ReplacingMergeTree](../../engines/table-engines/mergetree-family/replacingmergetree.md) tables are used with virtual `_sign` and `_version` columns.
- 
+
 - `_version` — Transaction counter. Type [UInt64](../../sql-reference/data-types/int-uint.md).
 - `_sign` — Deletion mark. Type [Int8](../../sql-reference/data-types/int-uint.md). Possible values:
-    - `1` — Row is not deleted, 
+    - `1` — Row is not deleted,
     - `-1` — Row is deleted.
 
 ## Data Types Support {#data_types-support}
@@ -103,7 +103,7 @@ MySQL DDL queries are converted into the corresponding ClickHouse DDL queries ([
 
 - MySQL `INSERT` query is converted into `INSERT` with `_sign=1`.
 
-- MySQL `DELETE` query is converted into `INSERT` with `_sign=-1`. 
+- MySQL `DELETE` query is converted into `INSERT` with `_sign=-1`.
 
 - MySQL `UPDATE` query is converted into `INSERT` with `_sign=-1` and `INSERT` with `_sign=1`.
 
@@ -146,9 +146,9 @@ mysql> SELECT * FROM test;
 ```
 
 ```text
-+---+------+------+ 
++---+------+------+
 | a |    b |    c |
-+---+------+------+ 
++---+------+------+
 | 2 |  222 | Wow! |
 +---+------+------+
 ```
@@ -175,9 +175,9 @@ SELECT * FROM mysql.test;
 ```
 
 ``` text
-┌─a─┬──b─┐ 
-│ 1 │ 11 │ 
-│ 2 │ 22 │ 
+┌─a─┬──b─┐
+│ 1 │ 11 │
+│ 2 │ 22 │
 └───┴────┘
 ```
 
@@ -188,8 +188,8 @@ SELECT * FROM mysql.test;
 ```
 
 ``` text
-┌─a─┬───b─┬─c────┐ 
-│ 2 │ 222 │ Wow! │ 
+┌─a─┬───b─┬─c────┐
+│ 2 │ 222 │ Wow! │
 └───┴─────┴──────┘
 ```
 

docs/en/engines/database-engines/mysql.md

@@ -53,7 +53,7 @@ All other MySQL data types are converted into [String](../../sql-reference/data-
 
 ## Global Variables Support {#global-variables-support}
 
-For better compatibility you may address global variables in MySQL style, as `@@identifier`. 
+For better compatibility you may address global variables in MySQL style, as `@@identifier`.
 
 These variables are supported:
 - `version`

docs/en/engines/database-engines/postgresql.md

@@ -14,7 +14,7 @@ Supports table structure modifications (`ALTER TABLE ... ADD|DROP COLUMN`). If `
 ## Creating a Database {#creating-a-database}
 
 ``` sql
-CREATE DATABASE test_database 
+CREATE DATABASE test_database
 ENGINE = PostgreSQL('host:port', 'database', 'user', 'password'[, `use_table_cache`]);
 ```
 
@@ -43,14 +43,14 @@ ENGINE = PostgreSQL('host:port', 'database', 'user', 'password'[, `use_table_cac
 | TEXT, CHAR       | [String](../../sql-reference/data-types/string.md)           |
 | INTEGER          | Nullable([Int32](../../sql-reference/data-types/int-uint.md))|
 | ARRAY            | [Array](../../sql-reference/data-types/array.md)             |
- 
+
 
 ## Examples of Use {#examples-of-use}
 
 Database in ClickHouse, exchanging data with the PostgreSQL server:
 
 ``` sql
-CREATE DATABASE test_database 
+CREATE DATABASE test_database
 ENGINE = PostgreSQL('postgres1:5432', 'test_database', 'postgres', 'mysecretpassword', 1);
 ```
 
@@ -102,7 +102,7 @@ SELECT * FROM test_database.test_table;
 └────────┴───────┘
 ```
 
-Consider the table structure was modified in PostgreSQL: 
+Consider the table structure was modified in PostgreSQL:
 
 ``` sql
 postgre> ALTER TABLE test_table ADD COLUMN data Text