Thomas,

> > I am also very skeptical about the "need" that to add this functionality to
> the Trace API, as it falls into the area of PSQL debugging/profiling which is 
> not
> what the current functionality is about*.
> 
> I don't propose to extend the Trace API in a way, which goes into debuging a
> stored procedure with all that stuff like local variable values etc.
> 
> IMHO this should be part of a separate Debug API, which AFAIK has been
> discussed in the past to expose something more reliable to third-party
> developer tools like Database Workbench, IBExpert ... than what they
> currently try to "simulate".

I am happy that you agree with the general functional boundaries.


> For databases, which are very PSQL-centric, which have a lot of business logic
> implemented in PSQL, the Trace API is not of that much use today,
> because:
> 
> * No I/O statistics for procedure/trigger trace events. According to Vlad, it
> should be available, he has a look on that

I agree that this is a problem.


> * Call of procedures inside a PSQL module are traced with their according
> procedure trace events, but no I/O statistics as above

Here I am not sure, I would tend to think that the analysis of "overhead" 
within a PSQL module should be a debugging task.

I am inclined to say that all I/O should be aggregated/reported at the module 
(directly called SP or primary invoked Trigger) level and not the sub-module 
level.


> * Embedded SQL statements in PSQL aren't available in the trace output,
> which seems to be a current/technical restriction

I agree that this is a problem.  But as with above, the I/O should be 
aggregated/reported at the module (EXECUTE BLOCK/EXECUTE STATEMENT) level.


Sean

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Reply via email to