> > 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*. 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
