RE: [HACKERS] Bug?

Michael Meskes <meskes@topsystem.de>

From: "Meskes, Michael" <meskes@topsystem.de>
To: Bruce Momjian <maillist@candle.pha.pa.us>, Tom I Helbekkmo <tih@Hamartun.Priv.NO>
Cc: meskes@topsystem.de, pgsql-hackers@postgreSQL.org
Date: 1998-02-08T10:16:33Z
Lists: 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"
>