From: | "Higuchi, Daisuke" <higuchi(dot)daisuke(at)jp(dot)fujitsu(dot)com> |
---|---|
To: | 'Michael Meskes' <meskes(at)postgresql(dot)org>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | RE: [Bug Fix] ECPG: could not use some CREATE TABLE AS syntax |
Date: | 2019-02-18 04:56:14 |
Message-ID: | 1803D792815FC24D871C00D17AE95905DB478E@g01jpexmbkw24 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 be changed in the future, there is a possibility that it will not be reflected in ECPG like this bug. Therefore, I thought that (b) was better and created a patch. And, in order to make it the simplest code, some SQL which is rejected in current 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 which SQL should be rejected in both ECPG and the backend? Following inappropriate SQL are accepted in ECPG but rejected by the backend (I am wondering why only CREATE TABLE .. AS .. INTO is rejected and other inappropriate SQL are accepted in current 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tsunakawa, Takayuki | 2019-02-18 05:01:09 | RE: Protect syscache from bloating with negative cache entries |
Previous Message | Michael Paquier | 2019-02-18 04:07:43 | Re: make installcheck-world in a clean environment |