Обсуждение: Problem with ecpg
============================================================================
POSTGRESQL BUG REPORT TEMPLATE
============================================================================
Your name : Bernard Isambert
Your email address : isambert@sib.fr
System Configuration
---------------------
Architecture (example: Intel Pentium) : Intel pentium
Operating System (example: Linux 2.0.26 ELF) : Linux 2.2.13
PostgreSQL version (example: PostgreSQL-6.5.3): PostgreSQL-7.0beta5
(and previous)
Compiler used (example: gcc 2.8.0) : any...
Please enter a FULL description of your problem:
------------------------------------------------
The problem is in the parsing of operators by ecpg (details below).
As a result, good or bad precompile depends on usage of spaces
in the source, where it should not.
Please describe a way to repeat the problem. Please try to provide a
concise reproducible example, if at all possible:
----------------------------------------------------------------------
Source file:
EXEC SQL BEGIN DECLARE SECTION;
VARCHAR hostvar[32];
EXEC SQL END DECLARE SECTION;
strcpy(hostvar.arr, "something");
EXEC SQL SELECT column2 FROM table1 WHERE column1 = :hostvar;
strcpy(hostvar.arr, "anything");
EXEC SQL SELECT column2 FROM table1 WHERE column1=:hostvar;
Ecpg parsing gives:
for the first select, with spaces around the = sign:
{ ECPGdo(__LINE__, NULL, "select column2 from table1 where column1 =
? ",
ECPGt_varchar,&(hostvar),32L,1L,sizeof(struct varchar_hostvar),
ECPGt_NO_INDICATOR, NULL, 0L, 0L, 0L, ECPGt_EOIT, ECPGt_EORT);}
for the second select, without spaces around (after) the = sign:
{ ECPGdo(__LINE__, NULL, "select column2 from table1 where column1
=: hostvar ",
ECPGt_EOIT, ECPGt_EORT);}
which is clearly different from the expected result
and yields a run-time error ...
If you know how this problem might be fixed, list the solution below:
---------------------------------------------------------------------
I suggest a workaround in the ecpg source "pgc.l"
(src/interfaces/ecpg/preproc/pgc.l):
diff pgc.l.orig pgc.l
192c192,194
< operator {op_chars}+
---
> /* op_mchars = op_chars but the ':' */
> op_mchars [\~\!\@\#\^\&\|\`\?\$\+\-\*\\/\%\<\>\=]
> operator {op_chars}{op_mchars}*
This forbids ":" to be the second (or above) char in an operator.
Is there any situation where it should be?
Or maybe the rule should be a bit more complex?
--
__________________________________________________
Bernard ISAMBERT (isambert@sib.fr)
Syndicat Interhospitalier de Bretagne (www.sib.fr)
__________________________________________________
Can someone comment on this patch?
> ============================================================================
>
> POSTGRESQL BUG REPORT TEMPLATE
> ============================================================================
>
>
>
> Your name : Bernard Isambert
> Your email address : isambert@sib.fr
>
>
> System Configuration
> ---------------------
> Architecture (example: Intel Pentium) : Intel pentium
>
> Operating System (example: Linux 2.0.26 ELF) : Linux 2.2.13
>
> PostgreSQL version (example: PostgreSQL-6.5.3): PostgreSQL-7.0beta5
> (and previous)
>
> Compiler used (example: gcc 2.8.0) : any...
>
>
>
> Please enter a FULL description of your problem:
> ------------------------------------------------
> The problem is in the parsing of operators by ecpg (details below).
> As a result, good or bad precompile depends on usage of spaces
> in the source, where it should not.
>
>
> Please describe a way to repeat the problem. Please try to provide a
> concise reproducible example, if at all possible:
> ----------------------------------------------------------------------
>
> Source file:
>
> EXEC SQL BEGIN DECLARE SECTION;
> VARCHAR hostvar[32];
> EXEC SQL END DECLARE SECTION;
>
> strcpy(hostvar.arr, "something");
>
> EXEC SQL SELECT column2 FROM table1 WHERE column1 = :hostvar;
>
> strcpy(hostvar.arr, "anything");
>
> EXEC SQL SELECT column2 FROM table1 WHERE column1=:hostvar;
>
>
> Ecpg parsing gives:
>
> for the first select, with spaces around the = sign:
>
> { ECPGdo(__LINE__, NULL, "select column2 from table1 where column1 =
> ? ",
> ECPGt_varchar,&(hostvar),32L,1L,sizeof(struct varchar_hostvar),
> ECPGt_NO_INDICATOR, NULL, 0L, 0L, 0L, ECPGt_EOIT, ECPGt_EORT);}
>
> for the second select, without spaces around (after) the = sign:
>
> { ECPGdo(__LINE__, NULL, "select column2 from table1 where column1
> =: hostvar ",
> ECPGt_EOIT, ECPGt_EORT);}
>
> which is clearly different from the expected result
> and yields a run-time error ...
>
>
> If you know how this problem might be fixed, list the solution below:
> ---------------------------------------------------------------------
>
> I suggest a workaround in the ecpg source "pgc.l"
> (src/interfaces/ecpg/preproc/pgc.l):
>
> diff pgc.l.orig pgc.l
> 192c192,194
> < operator {op_chars}+
> ---
> > /* op_mchars = op_chars but the ':' */
> > op_mchars [\~\!\@\#\^\&\|\`\?\$\+\-\*\\/\%\<\>\=]
> > operator {op_chars}{op_mchars}*
>
> This forbids ":" to be the second (or above) char in an operator.
> Is there any situation where it should be?
> Or maybe the rule should be a bit more complex?
>
> --
> __________________________________________________
>
> Bernard ISAMBERT (isambert@sib.fr)
> Syndicat Interhospitalier de Bretagne (www.sib.fr)
> __________________________________________________
>
--
Bruce Momjian | http://www.op.net/~candle
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Can someone comment on this patch?
>> This forbids ":" to be the second (or above) char in an operator.
>> Is there any situation where it should be?
It would surely be intolerable for ecpg to have different ideas about
what is an operator name than the postgres backend does. So I'm not
happy about patching ecpg this way without changing the backend.
However, we have already deprecated the ':' and ';' operators with
the intention of removing those operators in 7.1, and forbidding
those two characters entirely in operator names. So the problem
should go away in 7.1.
I haven't yet done the physical removal of ':' and ';' but it's on
the hit list...
regards, tom lane