On 12/14/19 1:55 PM, František Kučera wrote:
> Dne 14. 12. 19 v 18:20 Richard Damon napsal(a):
>> What he wants is different. He takes a basically arbitrary database
>> (user provided) and an arbitrary SQL statement (also user provided) and
>> he wants to determine what type a given column will
On 14 Dec 2019, at 6:55pm, František Kučera wrote:
> This is IMHO feasible, but would mean probably a lot of work. However it
> might be beneficial for those who come from other relational databases and
> prefer static typing rather than dynamic.
I don't think it's practical. For instance,
I just don't see the trouble
https://github.com/d3x0r/SACK/blob/master/src/SQLlib/sqlstub.c#L3613-L3680
for each row for each column
= sqlite3_column_type( collection->stmt, idx - 1 )
and then get the data according to the type... sqlite3_column_double (for
instance)
It's not very expensive to
Dne 14. 12. 19 v 18:20 Richard Damon napsal(a):
> What he wants is different. He takes a basically arbitrary database
> (user provided) and an arbitrary SQL statement (also user provided) and
> he wants to determine what type a given column will present.
Yes, I am looking for something that is
On 12/14/19 11:12 AM, Simon Slavin wrote:
> On 14 Dec 2019, at 10:46am, František Kučera wrote:
>
>> SELECT cast(dump+100 AS integer) FROM fstab;
>>
>> the sqlite3_column_decltype() still does not return the integer type.
>>
>> Would it be possible to modify this function or add a new one, to
On 14 Dec 2019, at 10:46am, František Kučera wrote:
> SELECT cast(dump+100 AS integer) FROM fstab;
>
> the sqlite3_column_decltype() still does not return the integer type.
>
> Would it be possible to modify this function or add a new one, to tell the
> correct type at least if there is an
On 12/14/19 5:22 AM, František Kučera wrote:
> Dne 14. 12. 19 v 9:36 Darren Duncan napsal(a):
>> With respect to SQLite, every column is the union of: Null, every Integer,
>> every Float, every Text, every Blob.
> OK, we can close this thread with that it is currently impossible to track
> the
dump+100 (string), pass+1000 (string)
the type information disappears and former integers becomes mere strings
There must be something else going on here:
Z:> sqlite3
SQLite version 3.30.1 2019-10-10 20:19:45
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use
P.S. Even if I do:
SELECT cast(dump+100 AS integer) FROM fstab;
the sqlite3_column_decltype() still does not return the integer type.
Would it be possible to modify this function or add a new one, to tell the
correct type at least if there is an explicit cast like this in given query?
If I
Dne 14. 12. 19 v 9:36 Darren Duncan napsal(a):
> With respect to SQLite, every column is the union of: Null, every Integer,
> every Float, every Text, every Blob.
OK, we can close this thread with that it is currently impossible to track the
declared column types through relational operations.
František,
Having done this myself, I will tell you that:
The only effective design for your "generic software that should work with any
database model" is that every column is the universal type, the union of all
other types; the type is the set of all representable values.
With respect to
On Friday, 13 December, 2019 18:35, Richard Damon
wrote:
>One big thing to watch out is that columns of NUMERIC type can easily
>return values of either INTEGER or REAL type. Your single type
>expectation is easily broken here. I also don't know if
>9223372036854775807 (the biggest integer
On 12/13/19 7:16 PM, František Kučera wrote:
> Dne 14. 12. 19 v 0:09 Keith Medcalf napsal(a):
>> On Friday, 13 December, 2019 15:49, František Kučera
>> wrote:
>>
>>> I know that SQLite uses dynamic types, so it is not easy… But what is the
>>> best way to determine the column type of a result
On 14 Dec 2019, at 12:16am, František Kučera wrote:
> In case of my software I can really expect that all values in a column will
> have the same type or be NULL (and everything else means error).
In that case, execute your query and use sqlite3_column_type() on each column
of the first row
Dne 14. 12. 19 v 0:09 Keith Medcalf napsal(a):
> On Friday, 13 December, 2019 15:49, František Kučera
> wrote:
>
>> I know that SQLite uses dynamic types, so it is not easy… But what is the
>> best way to determine the column type of a result set?
> Result sets do not have "column types". Each
On Friday, 13 December, 2019 15:49, František Kučera
wrote:
>I know that SQLite uses dynamic types, so it is not easy… But what is the
>best way to determine the column type of a result set?
Result sets do not have "column types". Each result value (the intersection of
row and column) has a
On 12/13/19 5:49 PM, František Kučera wrote:
> Hello,
>
> I know that SQLite uses dynamic types, so it is not easy… But what is the
> best way to determine the column type of a result set?
>
> The sqlite3_column_decltype() works only if I select directly a column, but
> not when I do some other
Hello,
I know that SQLite uses dynamic types, so it is not easy… But what is the best
way to determine the column type of a result set?
The sqlite3_column_decltype() works only if I select directly a column, but not
when I do some other operations (call function, increment etc.).
The
18 matches
Mail list logo
