On Tue, Apr 22, 2014 at 8:47 PM, Stephan Beal <sgb...@googlemail.com> wrote: > On Tue, Apr 22, 2014 at 8:25 PM, Dominique Devienne > <ddevie...@gmail.com>wrote: > >> Yet I don't see the point of a BIGINT either. A blob can effectively >> act as a arbitrary sized integer already, albeit one stored in base >> 256 and on which you cannot do arithmetic, but that's OK and enough to >> use it as a PK / FK. >> > > A blob can store raw binary data, i.e. raw integers from memory. Just be > sure to encode/decode them if you want their stored representations to be > platform-portable (big vs little endian). You can bind a blob using > (&myInt, sizeof(myInt)) if you really want to, it just won't be > platform-portable without settling on an encoding. If the goal is only > performance, though, it might (without encoding) be (marginally) faster > than using string-format data (be sure to use SQLITE_TRANSIENT when binding > the memory, too).
Thanks for the advise. No, I'm not binding endian-specific native C integer variables, but a uchar[16], so there are no endianness issues. I mentally assimilate GUIDs are integers, but the code deals with raw memory. --DD _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
