Thread: [HACKERS] Is it possible to get query_string value in an event trigger?
Hello. Is it possible to get the currently executing query in an event trigger, for example, a create table event trigger function firing after ddl_command_end, aside from checking pg_stat_activity for the current process?
When I am debugging the source code, after executing a statement I can see the variable query_string which has the entire SQL statement, however, I would be very interested if it's possible to get this query_string value in a c function called during an event trigger, for a given process, or if by that time the memory has been freed and/or it's just not possible for some other reason to get the query string of a particular process.
Any thoughts much appreciated.
:On Mon, May 22, 2017 at 2:18 PM, Jeremy Finzel <finzelj@gmail.com> wrote: > Hello. Is it possible to get the currently executing query in an event > trigger, for example, a create table event trigger function firing after > ddl_command_end, aside from checking pg_stat_activity for the current > process? > > When I am debugging the source code, after executing a statement I can see > the variable query_string which has the entire SQL statement, however, I > would be very interested if it's possible to get this query_string value in > a c function called during an event trigger, for a given process, or if by > that time the memory has been freed and/or it's just not possible for some > other reason to get the query string of a particular process. > > Any thoughts much appreciated. I don't think there's a totally reliable way to do it today. You could look at debug_query_string, but that's the toplevel query string, not necessarily the query string that fired the event trigger. It looks like ProcessUtilitySlow() has the query_string, but it's not passed down to EventTriggerDDLCommandStart(), EventTriggerDDLCommandEnd(), EventTriggerSQLDrop(), or EventTriggerTableRewrite(). In the first three cases, it seems like that would be pretty easy to change, but the last one looks harder. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company