OK. If system table triggers are generally not maintained, what is simplest recommended way, by C API or other means, for the application to be notified of non-specific schema changes that include creation/deletion events? In the vein of the columns meta-data eval.c tester I posted, it would be helpful if the application could be notified and automatically refresh its snapshot when tables or views arrive or depart the schema.
Regarding that eval.c test example. What is the status of implementing the small and sensible change for an optional row separator (third) parameter in the eval.c extension released with SQLite? I'd be happy to provide my changes. Let me know if you want them. On Wed, Sep 20, 2017 at 3:20 AM, Richard Hipp <d...@sqlite.org> wrote: > On 9/20/17, petern <peter.nichvolo...@gmail.com> wrote: > > What are the drawbacks to allowing triggers on system tables? Is this an > > arbitrary restriction? > > System tables are sometimes modified directly, without going through > the usual DELETE/INSERT/UPDATE logic. In order to support triggers on > system tables, logic to check for and invoke triggers would need to be > added to every place in the code that modifies system tables. This is > doable in theory, but is error prone, generates a lot of extra code > that is rarely used but takes up memory space on embedded devices and > must still be maintained, and is of questionable utility. > -- > D. Richard Hipp > d...@sqlite.org > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
