* Tom Lane ([EMAIL PROTECTED]) wrote: > Stephen Frost <[EMAIL PROTECTED]> writes: > > * Bruce Momjian ([EMAIL PROTECTED]) wrote: > >> Would you show an example of the invalid value this is trying to avoid? > > > Well, the way I discovered the problem was by sending a timestamp in > > double format when the server was expecting one in int64 format. > > Most of the time, though, this sort of error would still yield a valid > value that just failed to represent the timestamp value you wanted. > I'm unsure that a range check is going to help much.
I'm not sure I agree about the 'most of the time' comment- I havn't done extensive tests yet but I wouldn't be at all suprised if most of the time range around the current date, when stored as a double and passed to the database which is expecting an int64, would cause the problem. The issue isn't about the wrong date being shown or anything, it's that the database accepts the value but then throws errors whenever you try to view the table. The intent of the patch was to use the exact same logic to test if the date is valid on the incoming side as is used to test the date before displaying it. This would hopefully make it impossible for someone to run into this problem in the future. It would also make it much clearer to the programmer that the date he's passing is bad and not that there's some corruption happening in the database after the date is accepted. Stephen
Description: Digital signature