Re: [HACKERS] Numeric with '-'
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Numeric with '-' |
Дата | |
Msg-id | 4471.951322723@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Numeric with '-' (Peter Eisentraut <e99re41@DoCS.UU.SE>) |
Список | pgsql-hackers |
Peter Eisentraut <e99re41@DoCS.UU.SE> writes: > ... It seems pretty > clear to me that anything of the form [0-9]+ is an integer, something with > an 'e' in it is a float, and something with only digits and decimal points > is numeric. So 123456789012345678901234567890 is an integer? Not on the machines I use. Nor do I want to restrict 1234567890.1234567890e20 or 1e500 to be considered always and only floats; the first will drop precision and the second will overflow, whereas they are both perfectly useful as numeric. What I'd originally hoped was that we could postpone determining the type of a numeric literal until we saw where it was going to be used, as in Hiroshi's INSERT into t (numdata) values (-1234567890.1234567); example. Unfortunately that doesn't work in some other fairly obvious cases, like SELECT 1.2 + 3.4; you just plain don't have any other cues except the sizes and precisions of the constants to resolve the type here. So the original code was right, I think, to the extent that it looked at the precision and size of the constant to select a default type for the constant. But it wasn't right to lose the numeric-ness of the constant altogether when it doesn't fit in a double. What I'm testing now is code that generates either INT4, FLOAT8, or NUMERIC depending on precision and size --- but never UNKNOWN, which is what you'd get before with more than 17 digits. regards, tom lane
В списке pgsql-hackers по дате отправления: