Re: [sqlite] Format change to fts2 module.

2006-11-29 Thread Ralf Junker
Hello Scott Hess,

>http://www.sqlite.org/cvstrac/tktview?tn=2046 should fix this for fts1 and 
>fts2.

I have just tested them in both fts1 and fts2 and the reported problems no 
longer show! Many thanks for the fixes!

Please allow me to report some (compiler-independent) compiler warnings about 
fts:


* fts1.c:

Variable i is never used in function static char *firstToken(char *zIn, char 
**pzTail).

Variable j is never used in function static int parseSpec(TableSpec *pSpec, int 
argc, const char *const*argv, char**pzErr)


* fts2.c:

Both warnings above also apply to fts2.


* SQLITE_EXTENSION_INIT1

If I compile both fts1 and fts2 into the same executable with

  -DSQLITE_CORE=1
  -DSQLITE_ENABLE_FTS1=1
  -DSQLITE_ENABLE_FTS2=1

I receive a linker warning that sqlite3_api is defined in both fts1.c and 
fts2.c.

The warning goes away if I remove SQLITE_EXTENSION_INIT1 from both units. I 
might be wrong, but maybe this is not necessary if the library is compiled with 
SQLITE_CORE=1?

Regards,

Ralf 


-
To unsubscribe, send email to [EMAIL PROTECTED]
-



Re: [sqlite] Format change to fts2 module.

2006-11-28 Thread Scott Hess

http://www.sqlite.org/cvstrac/tktview?tn=2046 should fix this for fts1 and fts2.

-scott

On 11/21/06, Ralf Junker <[EMAIL PROTECTED]> wrote:

Hello Scott Hess,

>>Not directly related to the format change, but did you have a chance
>>to look at ticket #2046?
>
>Yes, I took a look at it - I _believe_ that it's not actually an issue
>with fts2, because the sequence of virtual-table calls don't really
>make sense.  I'm going to try implementing a simpler virtual table to
>isolate the problem better.

This is great news - especially since this problem is annoying me a lot. Please 
let me know if I can be of any help.

Ralf


-
To unsubscribe, send email to [EMAIL PROTECTED]
-




-
To unsubscribe, send email to [EMAIL PROTECTED]
-