> Now, it is probable that the core can be patched as you request by
> assigning affinity to constants during parsing, but I haven't had an
> opportunity to look into it and I would have to check very
> thoroughly that it will not brake something else if I do patch it
> for you. At this precise moment, I cannot look into it for you, but
> maybe later in the week I will have time.
I've just had a quick 5-minute look seems as I couldn't get the problem
out of my head! I think it won't be so simple since the affinity is used
to ensure correct index behaviour. If I set the affinity on parsing
TK_INTEGER, TK_STRING and TK_FLOAT then the indexing functions fail where
a table is indexed with NONE affinity (e.g. the table t1 in
analyse2.test).
Further, patching the end of sqlite3ExprAffinity(...) in expr.c à la
something like this...
if( pExpr->affinity==0 ){
if( op==TK_INTEGER ) return SQLITE_AFF_INTEGER;
if( op==TK_FLOAT ) return SQLITE_AFF_REAL;
if( op==TK_STRING ) return SQLITE_AFF_TEXT;
}
return pExpr->affinity;
}
also does not work, throwing up a number of failed tests - some trivial
(e.g. it seems that it is explicitly tested to the effect that '1' is not
the same as 1), some not so.
In both cases other functionality may be broken further down the line as
well. Now, whether this could be worked through, I do not know - and
certainly won't have time to attempt at present. My apologies! :o)
In my testing it has, however, thrown up an interesting curio in the sql
parser which I'll stick in its own post.
Cheers
Will
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
