A suggestion, instead of using an "integer code" make it a bit mask so that any 
and all permutataions of the defined events can be executed?
 
That way the tracing function can be installed, and the flag can be set to 
disabled. Effectively disabling trace. Not sure if thats something useful or 
not but just a thought.

   0x00   NO_TRACE
   0x01   SQL_BEGIN
   0x02   SQL_END
   0x04   TRIGGER_BEGIN
   0x08   TRIGGER_END  

    Etc...

Regards,
Ken


[EMAIL PROTECTED] wrote: The current interface definition for sqlite3_trace()
is as follows:

   void *sqlite3_trace(
      sqlite3 *db,                         /* Database connection */
      void(*xTrace)(void*, const char*),   /* Callback function */
      void *pArg                           /* 1st arg to callback */
   );

I would like to propose changing (enhancing) this as
follows:

   void *sqlite3_trace(
      sqlite3 *db,
      void(*xTrace)(void*, const char*, int),
      void *pArg
   );

The only change is in the signature of the callback function.
We have added an extra integer parameter at the end.  We 
propose that this extra parameter will be a integer code
that describes what the trace event is.  Choices for the
integer code might be:

   * The beginning of an SQL statement
   * The end of an SQL statement
   * The start of a trigger
   * The end of a trigger

New codes might be added in the future.

The current implementation only shows the beginning of an
SQL statement and so the integer code is not required.  We are
proposing to add more detailed tracing information and that
has inspired the desire to include the integer code in the
3rd parameter of the callback.

Legacy applications should continue to work.  You might get a 
compiler warning about a type mismatch on the 2nd parameter to
sqlite3_trace().  But calling a 2-parameter function with 3
parameters is suppose to be harmless in C.  So everything
should continue to work.  For this reason, we do not consider
this an incompatible change.

Please follow-up with criticisms or alternative approaches 
for this idea. Thanks.

--
D. Richard Hipp 



-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------


Reply via email to