On 20 Sep 2017, at 10:36pm, Simon Slavin wrote:
> This will tell you in some detail what kind of schema chance it taking place.
G. That should be
"This will tell you in some detail what kind of schema change is taking place."
Simon.
___
sqlite
On 20 Sep 2017, at 10:10pm, petern wrote:
> Instead of polling from a custom program, what would be nice is a feature
> within shell.c that permits the user to specify pre-execute SQL which
> optionally executes silently before every statement sent through the input
> line.
shell.c is part of
Instead of polling from a custom program, what would be nice is a feature
within shell.c that permits the user to specify pre-execute SQL which
optionally executes silently before every statement sent through the input
line. Testing SCHEMA_VERSION for changes as you suggest (and many other
useful
On 20 Sep 2017, at 6:55pm, petern wrote:
> 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?
https://sqlite.org/pr
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 he
On 9/20/17, petern 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
6 matches
Mail list logo
