They all need improvement or a better review or testcases or break
backwards compatibility.
The BIGINT or NCHAR stuff not, I would think ?
I'll have a look.
BIGINT leads to a backwards compatibility issue with largeint not being
recognized anymore. (not a real problem I think, but it must be
documented in user-changes)
then we can leave "largeint" and add "bigint" this will be safe in all
aspects. And largeint can be dropped later (as obsolete, non-standard).
And I think to fix this a revision has to be
reverted, not committed? Which leads to a new issue: we need to add a
test that test for the problem introduced with the revision being
reverted. (ie: recognition of fieldtypes when the first record is NULL)
yes this problem was revealed, but does not affect fix as I wrote in bug
tracker we must always rely on sqlite3_column_decltype()
and only when no useful information will be available then use as
workaround (or hack) sqlite3_column_type()
The nchar stuff doesn't have tests.
yes it is true, but they can be added later ... but NCHAR is not
supported by all databases so it must be implemented carefully
I don't even know if ftWideString
and such are working at all.
for me it works ... and as TWideStringField is descendant of
TStringField (which have tests), there is big chance, that it will work
The basic tests for these types have to be
added.
if some patches are problematic, then leave it for future ... but please
comment my list and let me know if I can do something to help.
IMHO at least points 4,5,6 are safe.
Thanks
Laco.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
