Re: [Chicken-users] Big integers as statement parameters in sql-de-lite

[Jim Ursetto]

It's not that the values are too large, it's that srfi 19 represents them as 
bignums, which is not currently supported by sql-de-lite. However, they work as 
floats (they will be converted to integers before being passed to the database, 
due to the column type).  Even on 32-bit systems, we fully support handling 53 
bit integers in the database in this way.

The easiest way to do this is by calling exact->inexact on the result to force 
it to floating point. Such a small value need not be a flonum on 64-bit system, 
but it will still work correctly, and it's the easiest way to ensure it is not 
a bignum.  You can confirm the value was stored as an integer by using the 
typeof() SQL function, e.g. select typeof(date) from foo;

Or you can just store the UNIX timestamp obtained from the posix unit, which 
should be a lot easier ;)

Jim

On Jul 22, 2013, at 18:18, Matt Gushee <address@hidden> wrote:

> Hi, Kon--
> 
> On Mon, Jul 22, 2013 at 4:34 PM, Kon Lovett <address@hidden> wrote:
> 
>> Do you need the range a SRFI-19 datetime provides? Maybe an epoch based 
>> approach, like provided by the posix module.
> 
> No, I don't need the range. In fact, my project is a lightweight
> blogging platform, and the date-times in question are creation and
> modification times for the content, which will normally be displayed
> to site visitors--possibly in localized formats; and other values
> having to do with authentication and sessions, which will normally be
> invisible. So I think it is safe to assume that all values that will
> ever be used will fall within a couple of decades beginning with 2013.
> 
> I'm not sure if I need to use SRFI-19. For some reason I thought that
> it would be preferable from the POV of  localized formatting and time
> zone conversions, but looking again at the docs it doesn't seem like
> that is necessary.
> 
> But I notice that the posix date/time functions work with values
> representing seconds, much like the values that are not working for
> me--except that in posix they are floats instead of integers. So maybe
> they won't cause errors? I'll give that a try.
> 
> --
> Matt Gushee
> 
> _______________________________________________
> Chicken-users mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/chicken-users