I wrote:
> My worry about that is for the (unlikely, but possible) case where a
> user gives a large number as a constant in a query, believing it to be
> an integer. If we signal an error, the user will know that the number
> was out of range. If not, we may end up doing calculations on floats
> that the user wanted done on integers. This may mean losing accuracy,
> which is something you don't want to do behind the user's back.
Something just struck me... How's this for a workaround? It lets you
enter large floats that happen to be integral without any explicit
indication of the fact that they are floats, which was the original
intent of this whole thread, while letting the user know that we're
doing it. In effect, we're saying "sure, you can do this on the fly,
and we'll do the right thing, but please be explicit in stored code".
Here's the modified code -- reindented for email purposes:
{integer} {
char* endptr;
errno = 0;
yylval.ival = strtol((char *)yytext,&endptr,10);
if (*endptr != '\0' || errno == ERANGE) {
errno = 0;
yylval.dval = strtod(((char *)yytext),&endptr);
if (*endptr != '\0' || errno == ERANGE) {
elog(ERROR,"Bad integer input '%s'",yytext);
return (ICONST);
}
elog(NOTICE,"Out of range integer '%s' promoted to float",yytext);
CheckFloat8Val(yylval.dval);
return (FCONST);
}
return (ICONST);
}
I don't know how the NOTICE is treated in all situations, though. If
the user doesn't see it, there isn't much point in having it. What
happens for the various interface methods? Will it be shown to a user
accessing a database from MS Excel using ODBC, for instance?
-tih
--
Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"