Michael Paquier <michael.paqu...@gmail.com> writes: > I recall discussions about reverse engineering of a parsed query tree in > the event trigger threads but nothing has been committed I think. Also, you
Yes. The name used in there was "Normalized Command String". > need to consider that implementing such reverse engineering mechanism in > core might not be a good thing for new features and maintenance, as it > would mean that it is necessary to change those APIs consistently with what > is added on the parsing side. The goal is to retain the same API, which is quite simple: function get_command_string(Node *parsetree) returns text At the SQL level, the Node * is of datatype "internal" and you can't forge it, you need to be given it in some ways. In the Event Trigger case we though of a TG_PARSETREE magic variable, or maybe another function get_current_parsetree() that only work when called from an event trigger. The other part of the API of course is how to represent the data, and as we're talking about a Normalized Command String, there's no choice but issuing a valid SQL command string that the server would know how to execute and which would have the same side effects. So of course a 9.3 and a 9.4 server equiped with that hypothetical function would behave differently when the syntax did change. And that's exactly why I think it the best choice here is to have that code embedded and maintained in core. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
