> Ah-hah, I've sussed it. numeric_in() was declared in pg_proc as
> taking one parameter, when in fact it takes three. Therefore, when
> calling it via fmgr (as the parser does), the second and third
> parameters were passed as random garbage. Apparently, the code
> generated for your machine produced some fairly harmless garbage...
> but not on mine.
> I've committed a pg_proc.h update to fix this...
Great.
> I'm still seeing
> regression=> insert into dnum values (12.34::numeric);
> ERROR: parser_typecast: cannot cast this expression to type 'numeric'
> which is arising from parser_typecast's inability to cope with
> a T_Float input node. I suspect it could be readily done along
> the same lines as T_Integer is handled, but I'll leave that to you.
postgres=> select 12.34::numeric;
--------
12.34
(1 row)
OK, and while I was looking at it I noticed that the T_Integer code
didn't bother using the int4out() routine to generate a string. imho
it should be using the official output routine unless there is some
compelling reason not to. It seems to still behave with this fix in
the T_Integer support code; should I commit both?
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California*** parse_expr.c.orig Tue Apr 27 14:14:13 1999
--- parse_expr.c Sun May 9 03:47:34 1999
***************
*** 642,650 ****
const_string = DatumGetPointer(expr->val.str);
break;
case T_Integer:
- const_string = (char *) palloc(256);
string_palloced = true;
! sprintf(const_string, "%ld", expr->val.ival);
break;
default:
elog(ERROR,
--- 642,653 ----
const_string = DatumGetPointer(expr->val.str);
break;
case T_Integer:
string_palloced = true;
! const_string = int4out(expr->val.ival);
! break;
! case T_Float:
! string_palloced = true;
! const_string = float8out(&expr->val.dval);
break;
default:
elog(ERROR,
