Re: [HACKERS] Bug?
От | Thomas G. Lockhart |
---|---|
Тема | Re: [HACKERS] Bug? |
Дата | |
Msg-id | 34DE97E1.51C5517D@alumni.caltech.edu обсуждение исходный текст |
Ответ на | RE: [HACKERS] Bug? (Tom I Helbekkmo <tih@Hamartun.Priv.NO>) |
Ответы |
Re: [HACKERS] Bug?
|
Список | pgsql-hackers |
> > 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
В списке pgsql-hackers по дате отправления: