Description:
The 2 commands SHOW BINLOG EVENTS and SHOW RELAYLOG EVENTS are probably not used frequently. The manual here: http://dev.mysql.com/doc/refman/5.7/en/show-binlog-events.html recommends using the external command mysqlbinlog to process information in the binlog or relaylogs of a server.
However, this is most inconvenient as it requires shell access to the server and a DBA would prefer to manage (except for stopping and starting the service) the MySQL service as much as possible from the SQL command prompt (locally or remotely).
Being able to examine the contents of the binlogs or relay logs can be most important for tools such as Orchestrator: (https://github.com/outbrain/orchestrator) and in contrast to something like MHA (https://code.google.com/p/mysql-master-ha/) which does require local access this local SQL access to the binlogs is very convenient.
Unfortunately, and especially with the introduction of RBR in replication the output of SHOW BINLOG EVENTS is quite basic and limited in the information it can provide compared to the output you can see if using the mysqlbinlog command line tool that comes with MySQL.
This complicates reading the information and thus makes it harder for tools such as Orchestrator to work effectively.
How to repeat:
Compare the output of mysqlbinlog with the output you can get from SHOW BINLOG EVENTS. The output of the former is much richer.
Whereas a few years ago no-one paid much attention to the binlogs with the growth of larger environments and the need to export information from MySQL into other systems using this stream of data becomes more interesting than it's traditional "just for replication" usage. Enhancing this feature would be very useful and allow the DBA or the application programmer to be able to manage the server much better without having to access the physical server to see this data and certainly for tools such as Orchestrator this would make things easier.
Suggested fix:
Provide an interface which is more complete so that more information that's available in the binlog events is extractable via the SQL command, and make this work for both STATEMENT and ROW-based replication and irrespective of whether GTID mode is enabled or not.
If you need to use a better syntax, such as SHOW FULL BINLOG EVENTS / SHOW FULL RELAYLOGS EVENTS that is good. It would also be convenient to be able to filter out some of the events using a filter. Perhaps SHOW BINLOG EVENTS WHERE ..... LIMIT ... OFFSET, as this would allow a user to look for specific entries (based on the columns which were specified) without having to pull all the data off the server.