Thanks for the comment.
At Tue, 6 Jul 2021 11:17:47 +0900, Michael Paquier <michael@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