On Fri, 6 Feb 1998, Bruce Momjian wrote:
> > Am I being dense here? Can there really be a significant performance
> > hit in the parsing of a query? Let's say that it takes a millisecond
> > extra to do the right thing with a number. Does it matter? How many
> > queries per second can we expect to process anyway?
>
> I don't know of standard ways to read in 64-bit integers.
Oh, sorry -- I wasn't being clear. Of course you don't, since we
don't even have standard 64-bit integers. My point was that I
couldn't see was how special handling of constants during the parsing
of the query string could have significant performance impact, even if
you did read them as 64-bit integers, which would mean adding bignum
code to PostgreSQL. In other words, performance isn't the argument to
be used against doing the right thing during parsing.
As for implementation, I was thinking more along the lines of:
{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);
}
CheckFloat8Val(yylval.dval);
return (FCONST);
}
return (ICONST);
}
However: do we really want to do this anyway? If you demand that the
user indicate whether a given constant is integer or real, you lessen
the risk of doing the wrong thing with his or her data. Specifically,
going to floating point means giving up accuracy in representation,
and this may not be something we want to do without user permission.
-tih
--
Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"