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


Reply via email to