Thread: Function call problems with BETWEEN

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

> 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

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