>>> I don't say that we don't need true debugger\profiler, no. But don't >>> limit trace functionality artificially. >> >> Personally, I agree that custom (user generated) trace events could be a >> useful addition, as they extend the application specific auditing tasks. >> But I'm quite skeptic about the gain the PSQL statement level tracing >> introduces, unless you plan to have future debugging/profiling tools being >> based on (and extending) user trace sessions -- but this is what surely >> deserves a public discussion. > > I agree, extending the current functionality to the PSQL statement level > requires a very public discussion. > > 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". 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 * Call of procedures inside a PSQL module are traced with their according procedure trace events, but no I/O statistics as above * Embedded SQL statements in PSQL aren't available in the trace output, which seems to be a current/technical restriction So, back to Sean's terminology, I fully agree that micro level information should be part of a separate PSQL Debug API, which tool developers can use to offer a full-featured debugger front-end. What the Trace API currently offers in respect to PSQL is just that a SP was executed, so, for the Trace API user, that's kind of a black-box. Regards, Thomas > Sean > > * the issue is that whether the Trace API could provide the functionality, > but rather should it -- in the larger context of the requirements/features of > a PSQL debugger/profiler. The Trace API is about collecting macro/higher > level details/statistics about the operations of a database, a PSQL > debugger/profiler is about the micro level -- with completely different > levels of interactions between the external user and the engine/debugger. > > > ------------------------------------------------------------------------------ > 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 > ------------------------------------------------------------------------------ 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
