>We just experienced the hard way that overloading certain built-in SQL >function can interfere with core SQL commands if the overloaded function >behaves differently from the built-in function. > >Not surprising, after looking at the sources: > >* ALTER TABLE - alter.c uses SUBSTR and LIKE. >* VACUUM - vacuum.c uses SUBSTR, LIKE, and QUOTE. >* Possible others? > >Would it be possible that the SQLite core always uses the built-in >functions instead of the overloaded ones? Or should overloading be >disabled for "core critical" SQL functions? > >If not, maybe those "critical" functions could be mentioned in the >documentation to warn developers that strange things might happen if >they change their behavior? > >IMHO, LIKE is especially critical since it is a likely candidate for >overriding to add UNICODE LIKE to applications.
Your finding is scary. At first glance my Unicode-twisted LIKE won't mess up things, but my LIKE works with unaccented versions of strings, so all bets are off w.r.t. usage in database integrity critical operations... IMVHO, the core definitely should call an internal _...@_like_@_ aliased to the original core version. The same for your other discovers, of course. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
