SQLite Forum

Type of the column
Login
>Do I understand correctly that the second one exist for 64-bit builds? If not - shouldn't there be SQLITE_INTEGER and SQLITE_INTEGER64?

>Or is there a better way to distinguish? Or I should be using _int4() all the time?

I will assume _int4() is a typo and you meant _int64() there.

The answer is No, it has nothing to do with whether you are running a 64-bit or 32-bit application. It has strictly to do with the size of the target variable/memory you want the value of the column to be written to.

If you expect the values to always be smaller than 4-billion, then a 32-bit integer target will do just fine. (These happens to be smaller space-wise, more space-efficient to transfer in say an internet stream, and also used to be faster to do calculations with on older 32-bit systems, hence still prevailing through esp. legacy code.)

If however you expect values bigger than that, you need to provide a memory-box that is big enough to hold them, regardless of CPU/Application bitness.

16-bit, 32-bit and 64-bit are just the comfortable options we have that covers most use cases for nicely packaged byte-sizes and so are supplied freely in every compiler system and also why CPUs over the years chose to do their direct interactions at these sizes. Today they are all 64-bit and so far we haven't seen 128-bit being needed a lot, but maybe one day it will.

Some applications need values even bigger, like astronomy systems using perhaps 80-bit integer variables. These applications have to provide their own 80-bit variable spaces and perhaps their own code for doing calculation with them. The point here is that the memory/variable sizes holding the data is dependent on the use case of the data, NOT the bitness of the application, underlying CPU, or Operating system, etc.

You want to carry around a variable that is yay-big, you need to provide a box that is yay-big, and if that happens to be a 32-bit or 64-bit box, then SQLite can hand it off to you natively using the said functions, else you would perhaps need to read it as a string or Blob and convert it yourself.


Use what you need - but beware, if a value bigger than 4 billion is stored in the DB and you try read it with the _int32() function, the result might be surprising, so make sure you know the target use case and impose the limits as needed in your application.


>Please advice.

You have been adviced. :)  
Good luck!