* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > * Bruce Momjian (pgman@candle.pha.pa.us) 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
