Thanks for the comment. At Tue, 6 Jul 2021 11:17:47 +0900, Michael Paquier <mich...@paquier.xyz> wrote in > On Thu, Jul 01, 2021 at 06:45:25PM +0900, Kyotaro Horiguchi wrote: > > Separating "CREATE TABLE AS EXECUTE" from ExecuteStmt would be cleaner > > but I avoided to change the syntax tree. Instead the attched make > > distinction of $$.type of ExecuteStmt between NULL and "" to use to > > notify the returned name is name of a prepared statement or a full > > statement. > > I am not so sure, and using an empty string makes the code a bit > harder to follow. How would that look with the grammar split you have
I agree to that. > in mind? Maybe that makes the code more consistent with the PREPARE > block a couple of lines above? More accurately, I didn't come up with the way to split out some of the rule-components in a rule out as another rule using the existing infrastructure. preproc.y: ExecuteStmt: EXECUTE prepared_name execute_param_clause execute_rest {} | CREATE OptTemp TABLE create_as_target AS EXECUTE prepared_name execute_param_clause opt_with_data execute_rest {} | CREATE OptTemp TABLE IF_P NOT EXISTS create_as_target AS EXECUTE prepared_name execute_param_clause opt_with_data execute_rest {} ; I can directly edit this as the following: ExecuteStmt: EXECUTE prepared_name execute_param_clause execute_rest {} ; CreateExecuteStmt: | CREATE OptTemp TABLE create_as_target AS EXECUTE prepared_name execute_param_clause opt_with_data execute_rest {} | CREATE OptTemp TABLE IF_P NOT EXISTS create_as_target AS EXECUTE prepared_name execute_param_clause opt_with_data execute_rest {} ; Then add the following component to the rule "stmt". | CreateExecuteStmt: { output_statement(..., ECPGst_normal); } regards. -- Kyotaro Horiguchi NTT Open Source Software Center