RE: [HACKERS] Bug? - Mailing list pgsql-hackers

From Meskes, Michael
Subject RE: [HACKERS] Bug?
Date
Msg-id 11720CEF3853D011AC0C00A024B7A9E110A13C@EINSTEIN
Whole thread Raw
Responses RE: [HACKERS] Bug?  (Tom I Helbekkmo <tih@Hamartun.Priv.NO>)
List pgsql-hackers
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"
>

pgsql-hackers by date:

Previous
From: "Meskes, Michael"
Date:
Subject: RE: [HACKERS] Bug?
Next
From: Tom I Helbekkmo
Date:
Subject: RE: [HACKERS] Bug?