RE: [Bug Fix] ECPG: could not use some CREATE TABLE AS syntax - Mailing list pgsql-hackers

From Higuchi, Daisuke
Subject RE: [Bug Fix] ECPG: could not use some CREATE TABLE AS syntax
Date
Msg-id 1803D792815FC24D871C00D17AE95905DB478E@g01jpexmbkw24
Whole thread Raw
In response to Re: [Bug Fix] ECPG: could not use some CREATE TABLE AS syntax  (Michael Meskes <meskes@postgresql.org>)
Responses Re: [Bug Fix] ECPG: could not use some CREATE TABLE AS syntax
List pgsql-hackers
Hi, Meskes-san, 

Thanks for your response! 

> I beg to disagree, or I don't understand. Why would ecpg's changes to 
> the statement be wrong nowadays?

I might confuse you, but it does not mean that it is wrong to reject CREATE TABLE AS ... INTO ... syntax in ECPG. 

My goal is to accept syntax which is currently rejected by ECPG. To realize that, I am considering following two ways:
(a) new syntax of create as statement should be added to ECPG
(b) make ECPG to use not ecpg.trailer but gram.y in the syntax of create as statement

In (a), we need to keep similar codes in both ecpg.trailer and gram.y. Also, if the syntax of create as statement will
bechanged in the future, there is a possibility that it will not be reflected in ECPG like this bug. Therefore, I
thoughtthat (b) was better and created a patch. And, in order to make it the simplest code, some SQL which is rejected
incurrent ECPG is accepted in my patch's ECPG.
 

> The statement CREATE TABLE a AS SELECT * INTO test FROM a; is accepted 
> with your patch, but it is not accepted in current ecpg nor is it accepted 
> by the backend when you execute it through ecpg. 

Indeed, CREATE TABLE a AS SELECT * INTO test FROM a; is accepted in my patch's ECPG, but the backend always reject, but
whichSQL should be rejected in both ECPG and the backend? Following inappropriate SQL are accepted in ECPG but rejected
bythe backend (I am wondering why only CREATE TABLE .. AS .. INTO is rejected and other inappropriate SQL are accepted
incurrent ECPG. ).
 
- EXEC SQL delete from test where c1 = (select into c2 from test2);

From the viewpoint of compatibility, if (b) is not good, I will consider (a) solution like following:

diff --git a/src/interfaces/ecpg/preproc/ecpg.trailer b/src/interfaces/ecpg/preproc/ecpg.trailer
@@ -34,7 +34,14 @@ CreateAsStmt: CREATE OptTemp TABLE create_as_target AS {FoundInto = 0;} SelectSt
                        if (FoundInto == 1)
                                mmerror(PARSE_ERROR, ET_ERROR, "CREATE TABLE AS cannot specify INTO");
 
-                   $$ = cat_str(6, mm_strdup("create"), $2, mm_strdup("table"), $4, mm_strdup("as"), $7);
+                 $$ = cat_str(7, mm_strdup("create"), $2, mm_strdup("table"), $4, mm_strdup("as"), $7, $8);
+         }
+                |  CREATE OptTemp TABLE IF_P NOT EXISTS create_as_target AS {FoundInto = 0;} SelectStmt opt_with_data
+         {
+                 if (FoundInto == 1)
+                         mmerror(PARSE_ERROR, ET_ERROR, "CREATE TABLE AS cannot specify INTO");
+
+                 $$ = cat_str(7, mm_strdup("create"), $2, mm_strdup("table if not exists"), $7, mm_strdup("as"), $10,
$11);
                }
                ;

I also want to hear your opinion. I will change my opinion flexibly. 

Regards, 
Daisuke, Higuchi


pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: make installcheck-world in a clean environment
Next
From: "Tsunakawa, Takayuki"
Date:
Subject: RE: Protect syscache from bloating with negative cache entries