Re: [Bug Fix] ECPG: could not use some CREATE TABLE AS syntax

Поиск
Список
Период
Сортировка
От Michael Meskes
Тема Re: [Bug Fix] ECPG: could not use some CREATE TABLE AS syntax
Дата
Msg-id 986e2ec88853817ce9edc9398cfd79772592eb37.camel@postgresql.org
обсуждение исходный текст
Ответ на RE: [Bug Fix] ECPG: could not use some CREATE TABLE AS syntax  ("Higuchi, Daisuke" <higuchi.daisuke@jp.fujitsu.com>)
Ответы RE: [Bug Fix] ECPG: could not use some CREATE TABLE AS syntax  ("Higuchi, Daisuke" <higuchi.daisuke@jp.fujitsu.com>)
Список pgsql-hackers
Hi Higuchi-san,

> 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

Correct.

> (b) make ECPG to use not ecpg.trailer but gram.y in the syntax of
> create as statement

I don't see how this would be possible to be honest.

> 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.

Yes, I fully understand that. However, in doing so you accept
statements that the backend later on rejects. The sole reason for the
big ecpg grammar is to prevent those cases whenever possible.

> 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. ).

That does sound like a bug to me. There may cases where it is not
possible to catch an invalid syntax for one reason or another. But I
would definitely go the extra mile to make the parsers as compatible as
possible.

> 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. 

I agree that this the way to go. 

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: Re: Copy function for logical replication slots
Следующее
От: Arthur Zakirov
Дата:
Сообщение: Re: [PATCH] xlogreader: do not read a file block twice