Обсуждение: Bug?
I'm currently back to work with version 6.2.1 since I cannot connect with 6.3 via ODBC. Anyway, I got my application running after finding a problem (inside the app) with data conversion (it read double from a long data field). But it seems I also encountered what I believe to be a bug. Since I'm nor sure whether it's known I bring it up here. If I try to insert 199802051215 to a float8 field it doesn't work because the parser believes this is a long and truncates it to 2147...... Using 199802051215.0 to make sure it's a float works fine. Shouldn't the parser be able to handle this? Michael -- Dr. Michael Meskes, Project-Manager | topsystem Systemhaus GmbH meskes@topsystem.de | Europark A2, Adenauerstr. 20 meskes@debian.org | 52146 Wuerselen Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44 Use Debian GNU/Linux! | Fax: (+49) 2405/4670-10
> I'm currently back to work with version 6.2.1 since I cannot connect with
> 6.3 via ODBC.
>
> Anyway, I got my application running after finding a problem (inside the
> app) with data conversion (it read double from a long data field). But it
> seems I also encountered what I believe to be a bug. Since I'm nor sure
> whether it's known I bring it up here. If I try to insert 199802051215 to a
> float8 field it doesn't work because the parser believes this is a long and
> truncates it to 2147...... Using 199802051215.0 to make sure it's a float
> works fine. Shouldn't the parser be able to handle this?
The current v6.3beta behavior is this:
postgres=> select 199802051215;
ERROR: Bad integer input '199802051215'
We had a bit of a discussion about the best way to handle this, and decided to
try Bruce's solution to reject the input as a first step. I have patches to do
the automatic conversion to a float, but have not applied them.
The other approach would lead to an error looking like:
postgres=> insert into t values (199802051215.0);
ERROR: pg_atoi: error reading "199802051215.000000": Math result not
representable
I can see arguments for both approaches; do you have a strong opinion either
way?
- Tom
> > I'm currently back to work with version 6.2.1 since I cannot connect with > 6.3 via ODBC. > > Anyway, I got my application running after finding a problem (inside the > app) with data conversion (it read double from a long data field). But it > seems I also encountered what I believe to be a bug. Since I'm nor sure > whether it's known I bring it up here. If I try to insert 199802051215 to a > float8 field it doesn't work because the parser believes this is a long and > truncates it to 2147...... Using 199802051215.0 to make sure it's a float > works fine. Shouldn't the parser be able to handle this? I think it converts it to an integer, and then by the time it tries to convert it, it has already chopped off the top of the number. The only fix for this would be to read all integers in as 64-bit integers, then do the conversion, but that could be a performance problem. -- Bruce Momjian maillist@candle.pha.pa.us
Bruce Momjian writes: > I think it converts it to an integer, and then by the time it tries to > convert it, it has already chopped off the top of the number. The only > fix for this would be to read all integers in as 64-bit integers, then > do the conversion, but that could be a performance problem. I agree. And performance is important. I think explicit type conversion is what we should do. Or is it asked for too much if the user has to add a ::float8 to the number? Michael -- Dr. Michael Meskes, Project-Manager | topsystem Systemhaus GmbH meskes@topsystem.de | Europark A2, Adenauerstr. 20 meskes@debian.org | 52146 Wuerselen Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44 Use Debian GNU/Linux! | Fax: (+49) 2405/4670-10
> I think it converts it to an integer, and then by the time it tries to > convert it, it has already chopped off the top of the number. The only > fix for this would be to read all integers in as 64-bit integers, then > do the conversion, but that could be a performance problem. Well, the other possibility is to try converting to float8 only if the int4 conversion fails. If both fail, then throw an elog(ERROR). I have patches for this...
Bruce Momjian said: > The only fix for this would be to read all integers in as 64-bit > integers, then do the conversion, but that could be a performance > problem. Michael Meskes answered: > I agree. And performance is important. I think explicit type > conversion is what we should do. Or is it asked for too much if the > user has to add a ::float8 to the number? 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? -tih -- Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"
> > Bruce Momjian said: > > > The only fix for this would be to read all integers in as 64-bit > > integers, then do the conversion, but that could be a performance > > problem. > > Michael Meskes answered: > > > I agree. And performance is important. I think explicit type > > conversion is what we should do. Or is it asked for too much if the > > user has to add a ::float8 to the number? > > 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. -- Bruce Momjian maillist@candle.pha.pa.us
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"
> 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. > I never auto-convert integer to float unless I have to. -- Bruce Momjian maillist@candle.pha.pa.us