Re: Problem with ecpg - Mailing list pgsql-bugs

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