Re: [QUESTIONS] UPDATE statement ORACLE 6 compatible

Started by Thomas G. Lockhartalmost 28 years ago5 messages
#1Thomas G. Lockhart
lockhart@alumni.caltech.edu

I am not absolutly happy with this because it looks like the
statement is not working correctly for 100%. It comes back with an
strange error message if the '%' sign is at the end of '40'!!..

select * from my_table where cast(my_int as text) like '40%';
ERROR: transformExpr: does not know how to transform node 103

Any ideas!..

Thomas, I believe this is the problem with my processing a node twice.
Do you have a fix for that, or should I make one?

tgl=> select * from t where cast(i as text) like '40%';
i
----
4030
(1 row)

So, the patch for "function() BETWEEN" helps, but I'm still not sure it
is safe, since I don't know how these nodes might be handled deeper in
the backend.

Also, one of my recent testing patches slightly breaks the type
conversion stuff so the numerology regression test fails on one of the
inserts and I haven't figured out which piece caused that. Nothing
should be affected in the CVS tree though.

- Tom

#2Bruce Momjian
maillist@candle.pha.pa.us
In reply to: Thomas G. Lockhart (#1)
Re: [HACKERS] Re: [QUESTIONS] UPDATE statement ORACLE 6 compatible

tgl=> select * from t where cast(i as text) like '40%';
i
----
4030
(1 row)

So, the patch for "function() BETWEEN" helps, but I'm still not sure it
is safe, since I don't know how these nodes might be handled deeper in
the backend.

Also, one of my recent testing patches slightly breaks the type
conversion stuff so the numerology regression test fails on one of the
inserts and I haven't figured out which piece caused that. Nothing
should be affected in the CVS tree though.

Ship the patch over here and I will have a look at 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)
#3Thomas G. Lockhart
lockhart@alumni.caltech.edu
In reply to: Bruce Momjian (#2)
1 attachment(s)
Re: [HACKERS] Re: [QUESTIONS] UPDATE statement ORACLE 6 compatible

So, the patch for "function() BETWEEN" helps, but I'm still not sure
it is safe, since I don't know how these nodes might be handled
deeper in the backend.

Ship the patch over here and I will have a look at it.

OK, here it is...

- Tom

Attachments:

parse_expr.c.patchtext/plain; charset=us-ascii; name=parse_expr.c.patchDownload
*** ../src/backend/parser/parse_expr.c.orig	Sun Mar  1 15:04:42 1998
--- ../src/backend/parser/parse_expr.c	Sun Mar 15 05:49:03 1998
***************
*** 301,306 ****
--- 301,321 ----
  				result = (Node *) expr;
  				break;
  			}
+ /* These nodes do _not_ come from the original parse tree.
+  * They result from parser transformation in this phase.
+  * At least one construct (BETWEEN/AND) puts the same nodes
+  *  into two branches of the parse tree. Hence, some nodes
+  *  are transformed twice. These nodes come from transforming
+  *  a function call. Let's try just passing them through...
+  * - thomas 1998-03-14
+  */
+ 		case T_Expr:
+ 		case T_Var:
+ 		case T_Const:
+ 			{
+ 				result = (Node *) expr;
+ 				break;
+ 			}
  		default:
  			/* should not reach here */
  			elog(ERROR, "transformExpr: does not know how to transform node %d",
#4Thomas G. Lockhart
lockhart@alumni.caltech.edu
In reply to: Thomas G. Lockhart (#1)
1 attachment(s)
Re: [HACKERS] Re: [QUESTIONS] UPDATE statement ORACLE 6 compatible

Thomas, I believe this is the problem with my processing a node
twice. Do you have a fix for that, or should I make one?

So, the patch for "function() BETWEEN" helps, but I'm still not sure
it is safe, since I don't know how these nodes might be handled deeper
in the backend.

Bruce, did I remember to actually enclose the patch for you? Looks to me
like I didn't, so here it is again...

- Tom

Attachments:

parse_expr.c.patchtext/plain; charset=us-ascii; name=parse_expr.c.patchDownload
*** ../src/backend/parser/parse_expr.c.orig	Sun Mar  1 15:04:42 1998
--- ../src/backend/parser/parse_expr.c	Sun Mar 15 05:49:03 1998
***************
*** 301,306 ****
--- 301,321 ----
  				result = (Node *) expr;
  				break;
  			}
+ /* These nodes do _not_ come from the original parse tree.
+  * They result from parser transformation in this phase.
+  * At least one construct (BETWEEN/AND) puts the same nodes
+  *  into two branches of the parse tree. Hence, some nodes
+  *  are transformed twice. These nodes come from transforming
+  *  a function call. Let's try just passing them through...
+  * - thomas 1998-03-14
+  */
+ 		case T_Expr:
+ 		case T_Var:
+ 		case T_Const:
+ 			{
+ 				result = (Node *) expr;
+ 				break;
+ 			}
  		default:
  			/* should not reach here */
  			elog(ERROR, "transformExpr: does not know how to transform node %d",
#5Bruce Momjian
maillist@candle.pha.pa.us
In reply to: Thomas G. Lockhart (#3)
Re: [HACKERS] Re: [QUESTIONS] UPDATE statement ORACLE 6 compatible

This is a multi-part message in MIME format.
--------------5B2D8E5180AAC1149F41A1FA
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

So, the patch for "function() BETWEEN" helps, but I'm still not sure
it is safe, since I don't know how these nodes might be handled
deeper in the backend.

Ship the patch over here and I will have a look at it.

OK, here it is...

Applied. There is a nice comment, and it just prevents an elog(). I
think your logic is correct. There are several cases, I think, where
strings are used multiple places. Also, you are just preventing
reprocessing of the args. We can perhaps improve this later if a
problem comes up.

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