> Le 17 juil. 2017 à 20:54, Richard Hipp <d...@sqlite.org> 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 sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users