[Syntax] Change PREDICT to TO PREDICT (#1015)

* pass all tests in pkg/sql

* pass lexer test

* pass tests at pkg/sql/

Author: tonyyang-svail

README.md

@@ -44,7 +44,7 @@ Done training
 ```sql
 sqlflow> SELECT *
 FROM iris.test
-PREDICT iris.predict.class
+TO PREDICT iris.predict.class
 USING sqlflow_models.my_dnn_model;
 
 ...

cmd/sqlflowserver/main_test.go

@@ -551,7 +551,7 @@ INTO sqlflow_models.my_dnn_model;`, caseDB, caseTrainTable)
 	ParseRow(stream)
 	predSQL := fmt.Sprintf(`SELECT *
 FROM %s.%s
-PREDICT %s.%s.class
+TO PREDICT %s.%s.class
 USING sqlflow_models.my_dnn_model;`, caseDB, caseTestTable, caseDB, casePredictTable)
 
 	stream, err = cli.Run(ctx, sqlRequest(predSQL))
@@ -610,7 +610,7 @@ INTO sqlflow_models.my_dnn_model_custom;`
 
 	predSQL := `SELECT *
 FROM iris.test
-PREDICT iris.predict.class
+TO PREDICT iris.predict.class
 USING sqlflow_models.my_dnn_model_custom;`
 
 	stream, err = cli.Run(ctx, sqlRequest(predSQL))
@@ -1014,7 +1014,7 @@ INTO sqlflow_models.my_regression_model;`)
 
 	predSQL := fmt.Sprintf(`SELECT *
 FROM housing.test
-PREDICT housing.predict.target
+TO PREDICT housing.predict.target
 USING sqlflow_models.my_regression_model;`)
 
 	stream, err = cli.Run(ctx, sqlRequest(predSQL))
@@ -1090,7 +1090,7 @@ func CasePredictXGBoostRegression(t *testing.T) {
 
 	predSQL := fmt.Sprintf(`SELECT *
 FROM housing.test
-PREDICT housing.xgb_predict.target
+TO PREDICT housing.xgb_predict.target
 USING sqlflow_models.my_xgb_regression_model;`)
 
 	stream, err := cli.Run(ctx, sqlRequest(predSQL))

doc/design/design_ant_xgboost.md

@@ -62,7 +62,7 @@ INTO sqlflow_models.xgboost_model_table;
 select 
     c1, c2, c3, c4
 from kaggle_credit_fraud_development_data
-PREDICT kaggle_credit_fraud_development_data.class
+TO PREDICT kaggle_credit_fraud_development_data.class
 USING sqlflow_models.xgboost_model_table;
 ```
 

doc/design/design_clustermodel.md

@@ -38,12 +38,12 @@ USING existed_pretrain_model
 INTO my_cluster_model;
 ```
 
-PREDICT SQL:
+TO PREDICT SQL:
 
 ``` sql
 SELECT *
 FROM input_table
-PREDICT output_table.group_id
+TO PREDICT output_table.group_id
 USING my_cluster_model;
 ```
 
@@ -108,7 +108,7 @@ Therefore, there are four cases in total:
 
 - In the first stage of the clustering model on SQLFlow, we plan to achieve the `first case`. We will achieve the other cases in the later. 
 
-- Users can use the trained cluster model in ` PREDICT SQL` to predict the group of input_table to get output_table.
+- Users can use the trained cluster model in ` TO PREDICT SQL` to predict the group of input_table to get output_table.
 
 - Finally, the user can perform a combined aggregation operation on the output_table based on the SQL statement to obtain a result_table, which can be saved to the local dataframe and then analyzed according to his own needs.
 

doc/design/design_database_abstraction_layer.md

@@ -8,7 +8,7 @@ SQLFlow calls Go's [standard database API](https://golang.org/pkg/database/sql/)
 
 ### Data Retrieval
 
-The basic idea of SQLFlow is to extend the SELECT statement of SQL to have the TO TRAIN and PREDICT clauses.  For more discussion, please refer to the [syntax design](/doc/design/design_syntax.md).  SQLFlow translates such "extended SQL statements" into submitter programs, which forward the part from SELECT to TO TRAIN or PREDICT, which we call the "standard part", to the SQL engine.  SQLFlow also accepts the SELECT statement without TO TRAIN or PREDICT clauses and would forward such "standard statements" to the engine.  It is noticeable that the "standard part" or "standard statements" are not standardized.  For example, various engines use different syntax for `FULL OUTER JOIN`.
+The basic idea of SQLFlow is to extend the SELECT statement of SQL to have the TO TRAIN and TO PREDICT clauses.  For more discussion, please refer to the [syntax design](/doc/design/design_syntax.md).  SQLFlow translates such "extended SQL statements" into submitter programs, which forward the part from SELECT to TO TRAIN or TO PREDICT, which we call the "standard part", to the SQL engine.  SQLFlow also accepts the SELECT statement without TO TRAIN or TO PREDICT clauses and would forward such "standard statements" to the engine.  It is noticeable that the "standard part" or "standard statements" are not standardized.  For example, various engines use different syntax for `FULL OUTER JOIN`.
 
 - Hive supports `FULL OUTER JOIN` directly.
 - MySQL doesn't have `FULL OUTER JOIN`. However, a user can emulates `FULL OUTER JOIN` using `LEFT JOIN`, `UNION` and `RIGHT JOIN`.

doc/design/design_elasticdl_on_sqlflow.md

@@ -33,7 +33,7 @@ INTO trained_elasticdl_keras_classifier;
 SELECT
     c1, c2, c3, c4
 FROM prediction_data
-PREDICT prediction_results_table
+TO PREDICT prediction_results_table
 WITH
   num_classes = 10
 USING trained_elasticdl_keras_classifier;

doc/design/design_submitter.md

@@ -36,7 +36,7 @@ type TrainDescription struct {
 
 // SELECT *
 // FROM iris.test
-// PREDICT iris.predict.class
+// TO PREDICT iris.predict.class
 // USING sqlflow_models.my_dnn_model;
 type PredDescription struct {
     StandardSelect string // e.g. SELECT * FROM iris.test

doc/design/design_support_multiple_sql_statements.md

@@ -20,7 +20,7 @@ While splitting at the client-side is relatively simple to implement. We prefer
 
 ### Splitting Technique: Hybrid Parser vs. Lexer
 
-The hybrid parser solution uses the third-party SQL parser (like [TiDB parser](https://github.com/pingcap/parser/blob/master/parser.y)) and SQLFlow parser to determine the end of an SQL statement. The third-party SQL parser first parses the extended SQL statement. It will raise error near SQLFlow extended keywords, like TO TRAIN and PREDICT. Then the SQLFlow parser starts from the error position and stops at the end of the first statement. However, this solution relies on the third-party SQL parser to report the error **accurately** on the keywords, like TO TRAIN and PREDICT, that it can't recognize.
+The hybrid parser solution uses the third-party SQL parser (like [TiDB parser](https://github.com/pingcap/parser/blob/master/parser.y)) and SQLFlow parser to determine the end of an SQL statement. The third-party SQL parser first parses the extended SQL statement. It will raise error near SQLFlow extended keywords, like TO TRAIN and TO PREDICT. Then the SQLFlow parser starts from the error position and stops at the end of the first statement. However, this solution relies on the third-party SQL parser to report the error **accurately** on the keywords, like TO TRAIN and TO PREDICT, that it can't recognize.
 
 The lexer solution scans the entire SQL statements, finds the `;` tokens, and splits the SQL based on the position of  `;` token.
 

doc/design/design_syntax.md

@@ -131,7 +131,7 @@ Similarly, to infer the class (fraud or regular), we could
 
 ```sql
 SELECT * FROM kaggle_credit_fraud_development_data
-PREDICT kaggle_credit_fraud_development_data.class
+TO PREDICT kaggle_credit_fraud_development_data.class
 USING sqlflow_models.my_model_table;
 ```
 

doc/design/design_xgboost_on_sqlflow.md

@@ -24,7 +24,7 @@ The following example shows how to predict using the model `my_xgb_model`.
 
 ``` sql
 SELECT * FROM test_table
-PREDICT pred_table.result
+TO PREDICT pred_table.result
 USING my_xgb_model;
 ```
 
@@ -42,4 +42,4 @@ The code generator `codegen_xgboost.go` outputs an XGBoost program in Python. It
 1. It tells the SQL engine to run the SELECT statement and retrieve the training/test data. It saves the data into a text file, which could be loaded by XGBoost using the DMatrix interface.
 1. Parse and resolve the WITH clause to fill the `xgboost.train` arguments and the XGBoost Parameters.
 1. Save the trained model on disk.
-1. For the PREDICT clause, it loads the trained model and test data and then outputs the prediction result to a SQL engine.
+1. For the TO PREDICT clause, it loads the trained model and test data and then outputs the prediction result to a SQL engine.