> 1) in the parser transformations (and/or in the optimizer), look for
> unary minus operators on constants, and convert those node subtrees to
> negative constant nodes.
> 2) try to do the right thing to convert types to be compatible with
> target columns. I'm working on this topic now, but I'm planning on
> addressing functions (first cut is done) and operators (starting now)
> before looking at target columns. Hopefully all three areas will be
> Anyone interested in looking at (1)? I think it would be a good thing to
> have even if (2) masks the problem away, unless of course the optimizer
> already gets rid of function calls on constants by executing them before
I am confused. As I can tell, these are coming in as null_expr - 1.
Why can't we do a check in gram.y, and if it is a null_expr - 1, replace
to a negative constant of int or float8. The regular constant type
conversion code will then fix this.
Bruce Momjian | 830 Blythe Avenue
maillist(at)candle(dot)pha(dot)pa(dot)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)
In response to
pgsql-hackers by date
|Next:||From: Thomas G. Lockhart||Date: 1998-04-01 02:48:02|
|Subject: Re: [PORTS] Port Bug Report: int2 negative numbers not parsed correctly|
|Previous:||From: Tom Ivar Helbekkmo||Date: 1998-03-31 21:20:40|
|Subject: Re: [HACKERS] Re: [PATCHES] patches for 6.2.1p6|