Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> I've seen the same problems you are having, and reported them just as
> you have ("something is fundamentally wrong with numeric..."). And
> then the problems went away, but I'm not actually certain why.
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; it will take a full
rebuild and initdb to propagate the fix, of course.
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.
regards, tom lane
PS: can anyone think of a reasonable way of mechanically checking
pg_proc entries against the actual C definitions of the functions?
I grovelled through all the typinput functions by hand to verify
that numeric_in was the only one with this bug ... but I ain't
about to do that for all 989 pg_proc entries for built-in functions.
Much less to do it again for future releases.
