Re: [HACKERS] NUMERIC type conversions leave much to be desired
От | Thomas Lockhart |
---|---|
Тема | Re: [HACKERS] NUMERIC type conversions leave much to be desired |
Дата | |
Msg-id | 373507E8.70E2D9BE@alumni.caltech.edu обсуждение исходный текст |
Ответ на | Re: [HACKERS] NUMERIC type conversions leave much to be desired (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] NUMERIC type conversions leave much to be desired
|
Список | pgsql-hackers |
> 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,
В списке pgsql-hackers по дате отправления: