Re: [HACKERS] NUMERIC type conversions leave much to be desired

> 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(at)alumni(dot)caltech(dot)edu
South Pasadena, California