Re: [GSOC] questions about idea "rewrite pg_dump as library"
От | Dimitri Fontaine |
---|---|
Тема | Re: [GSOC] questions about idea "rewrite pg_dump as library" |
Дата | |
Msg-id | m2r4ig13io.fsf@2ndQuadrant.fr обсуждение исходный текст |
Ответ на | Re: [GSOC] questions about idea "rewrite pg_dump as library" (Michael Paquier <michael.paquier@gmail.com>) |
Список | pgsql-hackers |
Michael Paquier <michael.paquier@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
В списке pgsql-hackers по дате отправления: