Thread: RE: [HACKERS] Bug?
I like this code. I really do. I don't think accuracy is a problem. It
will work as it does right now if the number is a long. Only if it is
out of range it will go to float instead of giving back an error
message. Where could that be a problem?
Michael
--
Dr. Michael Meskes, Projekt-Manager | topystem Systemhaus GmbH
meskes@topsystem.de | Europark A2, Adenauerstr. 20
meskes@debian.org | 52146 Wuerselen
Go SF49ers! Use Debian GNU/Linux! | Tel: (+49) 2405/4670-44
> ----------
> From: Tom I Helbekkmo[SMTP:tih@Hamartun.Priv.NO]
> Sent: Samstag, 7. Februar 1998 04:53
> To: Bruce Momjian
> Cc: meskes@topsystem.de; pgsql-hackers@postgreSQL.org
> Subject: Re: [HACKERS] Bug?
>
> 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"
>
On Sun, 8 Feb 1998, Michael Meskes wrote: > Only if it is out of range it will go to float instead of giving > back an error message. Where could that be a problem? 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. -tih -- Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"
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"
> > 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".
> 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?
Per Tom H's suggestion; what do you think Bruce?
postgres=> select 100000000000;
NOTICE: Integer input '100000000000' is out of range; promoted to float
?column?
------------
100000000000
(1 row)
That would alleviate the "hidden" side effects, but still come closer to
doing something helpful...
- Tom
> Per Tom H's suggestion; what do you think Bruce? > > postgres=> select 100000000000; > NOTICE: Integer input '100000000000' is out of range; promoted to float > ?column? > ------------ > 100000000000 > (1 row) > > That would alleviate the "hidden" side effects, but still come closer to > doing something helpful... With the NOTICE, I like it. -- Bruce Momjian maillist@candle.pha.pa.us
Bruce Momjian wrote:
> > Per Tom H's suggestion; what do you think Bruce?
> >
> > postgres=> select 100000000000;
> > NOTICE: Integer input '100000000000' is out of range; promoted to float
> > ?column?
> > ------------
> > 100000000000
> > (1 row)
> >
> > That would alleviate the "hidden" side effects, but still come closer to
> > doing something helpful...
>
> With the NOTICE, I like it.
Will be done for v6.3 then. I'm finishing up on patches to gram.y to help
with CREATE FUNCTION, etc., wrt type names. Will commit the scan.l changes at
that time...
- Tom