Re: [HACKERS] numeric data type on 6.5
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] numeric data type on 6.5 |
Дата | |
Msg-id | 199905041723.NAA00660@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] numeric data type on 6.5 (Thomas Lockhart <lockhart@alumni.caltech.edu>) |
Список | pgsql-hackers |
> > > I'm looking at this right now. I had coded in a fallback to FLOAT8 for > > > the integer types because at the time that was the only other useful > > > numeric type. However, I'm going to try changing the code to leave a > > > failed INTx token as a string of unspecified type, which would be > > > typed and converted later using the automatic coersion mechanism. > > That would be good as far as it goes, but what about cases with a > > decimal point in 'em? Converting to float and then to numeric will > > lose precision. > > I'm inclined to think you should prevent the parser from converting > > *any* numeric constant out of string form until it knows the target data > > type. > > (IIRC, INT8 has problems similar to NUMERIC's...) > > Right. Here is a patch which tries to do something right for most > cases. For the "integer" token (numbers w/o a decimal point) it keeps > the token as a string if the conversion to int4 fails. I split the > "real" token into "decimal" (w/o exponent) and "real"; at the moment > "decimal" is forced to become a float8 if there are fewer than 18 > characters in the string, but there may be a more robust strategy to > be had. This seems like a perfect approach. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
В списке pgsql-hackers по дате отправления: