> Le 17 juil. 2017 à 20:54, Richard Hipp <[email protected]> a écrit :
>
> The 3.20.0 release will be delayed. Some concerns came up over the
> new sqlite3_value_pointer() interface. Interface chagnes were made
> over the weekend. But there are still concerns. So the decision has
> been made to back off and give the current design a few weeks to soak
> before trying to press forward with a release which will commit us to
> a particular design.
>
> The draft website is still up at https://sqlite.org/draft - note that
> the change log at https://sqlite.org/draft/releaselog/3_20_0.html now
> identifies three (obscure) backwards compatibility breaks. Your input
> on these changes is requested.
Hello,
When I read the documentation for sqlite3_bind_pointer, I read:
> The T parameter should be a static string
The reason is pretty clear: this T parameter will be used later by
sqlite3_value_pointer, for a string comparison with strcmp(). It hence has to
remain is memory forever - and static strings are good at that.
I could test it and make it work reliably in Swift for custom FTS5 tokenisers.
Here is my comment: I wonder if the key comparison with strcmp() is really
necessary.
First, this strcmp() give a lot of work to languages that wrap SQLite and lack
support for "static strings". Building a global \0-terminated buffer that never
gets deallocated is not always that easy :-)
Next, there are techniques for building unique "keys" that hold in a machine
word, and can simply be compared with ==. For example:
typedef void *sqlite3_pointer_key_t; // defined in sqlite3.h
sqlite3_pointer_key_t key1 = "my_key"; // nice for debugging
sqlite3_pointer_key_t key2 = &key2; // hard core but still valid
Maybe this is considered awful practices - I'm certainly not a C expert.
And this would also force functions that use the new pointer APIs to expose
those keys in some header (such as FTS5()). You may have chosen the current
technique precisely because you don't want such API pollution.
What were your rationale behind this choice?
Thanks in advance,
Gwendal Roué
_______________________________________________
sqlite-users mailing list
[email protected]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
