Thread

1. Function call problems with BETWEEN

   Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-03-11T04:20:08Z

   I think I've tracked down a problem I see using the BETWEEN operator:
   
   postgres=> select 1 where float8(1) between 0.0 and 2.0;
   ERROR:  transformExpr: does not know how to transform node 105
   postgres=> select 1 where float8(1) >= 0.0 and float8(1) <= 2.0;
   ?column?
   --------
          1
   (1 row)
   
   I'm pretty sure that the problem stems from the fact that in gram.y the
   BETWEEN clause is expanded into the AND clauses as in the second
   example, _but_ the parse tree for the function call is reused! So,
   transformExpr() is run twice on the same part of the parse tree, and
   does not know how to cope.
   
   Probably the strongest solution would be to copy the entire parse tree.
   Is there already a function to do that? It seems like it would be a lot
   of work to start this from scratch.
   
   Another possible solution would be to have transformExpr() accept a
   previously transformed parse tree without damaging it. A simple minded
   fix having transformExpr() ignore the T_Const (the "105" node in the
   example) and T_Var nodes did not work.
   
   Yet another solution would be to have transformExpr() replicate parse
   trees instead of having gram.y do it.
   
   Any thoughts on this?
   
                                                                - Tom
   
   
   

2. Re: [HACKERS] Function call problems with BETWEEN

   Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-03-11T04:44:38Z

   > I think I've tracked down a problem I see using the BETWEEN operator:
   >
   > postgres=> select 1 where float8(1) between 0.0 and 2.0;
   > ERROR:  transformExpr: does not know how to transform node 105
   >
   > I'm pretty sure that the problem stems from the fact that in gram.y the
   > BETWEEN clause is expanded into the AND clauses as in the second
   > example, _but_ the parse tree for the function call is reused! So,
   > transformExpr() is run twice on the same part of the parse tree, and
   > does not know how to cope.
   > ...
   
   > Another possible solution would be to have transformExpr() accept a
   > previously transformed parse tree without damaging it. A simple minded
   > fix having transformExpr() ignore the T_Const (the "105" node in the
   > example) and T_Var nodes did not work.
   
   Hmm. I forgot to set the return value for this. I now get:
   
   postgres=> select 1 where float8(1) between 0.0 and 2.0;
   ?column?
   --------
          1
   (1 row)
   
   But I'm not really happy putting in this change without knowing what the
   side effects might be. I'll go ahead and try the regression tests...
   
                                                  - Tom
   
   
   

3. Re: Function call problems with BETWEEN

   Bruce Momjian <maillist@candle.pha.pa.us> — 1998-03-11T04:49:23Z

   > Probably the strongest solution would be to copy the entire parse tree.
   > Is there already a function to do that? It seems like it would be a lot
   > of work to start this from scratch.
   > 
   > Another possible solution would be to have transformExpr() accept a
   > previously transformed parse tree without damaging it. A simple minded
   > fix having transformExpr() ignore the T_Const (the "105" node in the
   > example) and T_Var nodes did not work.
   > 
   > Yet another solution would be to have transformExpr() replicate parse
   > trees instead of having gram.y do it.
   > 
   > Any thoughts on this?
   
   I am sure copyfuncs.c has some function to do this, but these are
   parse-specific structures.  Not sure if they do have such functions.  I
   considered the reuse a possible problem when I wrote the code, but could
   not find any problems, so I left it.
   
   -- 
   Bruce Momjian                          |  830 Blythe Avenue
   maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
     +  If your life is a hard drive,     |  (610) 353-9879(w)
     +  Christ can be your backup.        |  (610) 853-3000(h)