On 10 Sep 2010, at 6:01pm, Andrew Wood wrote:
> One related question. The library Im using maps numeric types to one of
> the following C types:
>
> unsigned long int
> signed long int
> unsigned int (short)
> signed int (short)
> float
> double
>
> How does SQLite distinguish between ordinary
Andrew Wood wrote:
> One related question. The library Im using maps numeric types to one of
> the following C types:
>
> unsigned long int
> signed long int
> unsigned int (short)
> signed int (short)
> float
> double
>
> How does SQLite distinguish between ordinary floats and doubles, and
> be
On 09/09/10 00:01, Igor Tandetnik wrote:
> No. sqlite3_column_type returns the type of the value in the given column and
> the current row. The type reported by sqlite3_column_type may change from row
> to row. It is largely unrelated to the type "you originally intended the
> column to be" (SQL
On 9 Sep 2010, at 7:13am, Max Vlasov wrote:
> But if you write something universal, also have in mind that sqlilte won't
> raise any exception, for example if you try to read an integer, but there's
> a text stored there, you won't get an error, just zero as a result
Two different situations can
On Thu, Sep 9, 2010 at 1:01 AM, Andrew Wood wrote:
> Because I'm writing glue code between the SQLite API and a higher level
> library which provides a standard API across several DBMSs.
>
>
Have in mind that storage class is not a 'type', it's more like an effective
way to store values compactly
Simon Slavin wrote:
> I was attempting to find a value which would always coerce directly to the
> affinity of the column, so when you read it back out
> it would always be the 'proper' type. My theory would be that this one value
> could be used to betray the affinity of every
> column in a ta
On 9 Sep 2010, at 1:13am, Igor Tandetnik wrote:
> Simon Slavin wrote:
>> What would happen if you wrote a row with '1.1' for every value, then used
>> sqlite3_column_type when you read it back out ?
>> Assuming that it was possible (i.e. no TRIGGER or UNIQUE prevented it).
>
> It depends. If
Simon Slavin wrote:
> On 9 Sep 2010, at 12:01am, Igor Tandetnik wrote:
>
>> sqlite3_column_type returns the type of the value in the given column and
>> the current row. The type reported by
>> sqlite3_column_type may change from row to row. It is largely unrelated to
>> the type "you originall
On 9 Sep 2010, at 12:01am, Igor Tandetnik wrote:
> sqlite3_column_type returns the type of the value in the given column and the
> current row. The type reported by sqlite3_column_type may change from row to
> row. It is largely unrelated to the type "you originally intended the column
> to be
On Wed, Sep 08, 2010 at 07:01:19PM -0400, Igor Tandetnik wrote:
> Schrum, Allan wrote:
> > I guess I'm confused as to why sqlite3_column_type() would not work? It
> > works for me on queries and I get back either
> > SQLITE_INTEGER, SQLITE_FLOAT, or SQLITE3_TEXT. While I know the types could
> >
Schrum, Allan wrote:
> I guess I'm confused as to why sqlite3_column_type() would not work? It works
> for me on queries and I get back either
> SQLITE_INTEGER, SQLITE_FLOAT, or SQLITE3_TEXT. While I know the types could
> be coerced to something else, at least it is an
> answer of what you orig
On Wed, Sep 8, 2010 at 5:01 PM, Andrew Wood wrote:
> Because I'm writing glue code between the SQLite API and a higher level
> library which provides a standard API across several DBMSs.
>
> In other DBMSs even if a field contains null you can still ask the API
> what type it 'should' have been
On 8 Sep 2010, at 10:36pm, Jay A. Kreibich wrote:
> I also have to say that handling NULLs as a value-less type is a very
> clean and handy model.
Today at work I had to thoroughly investigate a program I wrote long ago and
look for places where NULL, undefined, -1 and 'false' might appear th
...@sqlite.org] On Behalf Of Jay A. Kreibich
> Sent: Wednesday, September 08, 2010 3:37 PM
> To: General Discussion of SQLite Database
> Subject: Re: [sqlite] Detecting storage class from C
>
> On Wed, Sep 08, 2010 at 10:01:48PM +0100, Andrew Wood scratched on the
> wall:
> >
On Wed, Sep 08, 2010 at 10:01:48PM +0100, Andrew Wood scratched on the wall:
> Because I'm writing glue code between the SQLite API and a higher level
> library which provides a standard API across several DBMSs.
>
> In other DBMSs even if a field contains null you can still ask the API
> what
Because I'm writing glue code between the SQLite API and a higher level
library which provides a standard API across several DBMSs.
In other DBMSs even if a field contains null you can still ask the API
what type it 'should' have been if something *had* been put in it.
Without this ability, I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/02/2010 06:52 PM, Andrew Wood wrote:
> Yes but none of those functions return the class that the declared type
> maps to (SQLITE_TEXT, SQLITE_FLOAT etc), they just return the SQL type
> as a string, of which there are umpteen possibilities.
>
> My reason for doing this is, if a field is null, I still need to know
> what class it 'should' have been if it had been storing a value.
Why do you need that? No matter what you declare field can store any
type of data. And in SQLite there's no "declared storage class". You
are talking either ab
Yes but none of those functions return the class that the declared type
maps to (SQLITE_TEXT, SQLITE_FLOAT etc), they just return the SQL type
as a string, of which there are umpteen possibilities.
Presumably then Im going to have to map them to the class myself? My
question was, is this the c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/31/2010 06:33 AM, Andrew Wood wrote:
> I need to detect the declared storage class of a field rather than the
> actual type stored, but as I understand it sqlite3_column_decltype
> returns the SQL type not the SQLite storage class? Is there a w
I need to detect the declared storage class of a field rather than the
actual type stored, but as I understand it sqlite3_column_decltype
returns the SQL type not the SQLite storage class? Is there a way to get
this info?
___
sqlite-users mailing list
21 matches
Mail list logo