rationale: 1) you start using the lib, do some calculations involving db storage, some time later realize that they are somewhat off, start digging where the hell it goes wrong, waste a lot of time looking at too many things until you finally realize that 7/10 written to the database silently comes back as something else than 7/10.
But.... 7/10 will be written as 0.7 just fine. Of course, this holds for 1/3, but there's no way to do that right, so in effect we'd be disallowing the writing of rationals to the db (except in cases where the divisor is guaranteed to be something like 10 or 4).
then: 2) user stars using lib, stores ratios in db, at some point faces a descriptive error message which includes a hint about the above mentioned special, reads up on the issue if necessary, based on necessary understanding of the issue decides to add required coercions to his code or to set/bind the special to T.
Well, what I'm afraid of is 3) the user has been happily running a system on top of CL-Postgres, upgrades, and suddenly finds his system crashing. That's a bad thing, no?
Cheers, Marijn