>> > Well, either they want that or they want that output more >> > accessibly, and without all the baggage that pg_dump necessarily >> > brings to the table. pg_dump does a lot of stuff that's basically >> > designed for bulk operations, and often what people want is a way to >> > get, say, the creation DDL for some object, without any locks than >> > the usual locks any transaction takes. >> >> Yes- being able to get that from a simple database function would be >> very nice. I wonder if some of what's been done with the "event" >> triggers would inform us about what that API should look like. >> > 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 > 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. > It could make more sense to have such a set of functions created as a > separate project.
This may or may not related to, but... pgpool-II already does "reverse engineering" from a parsed query. It parses a query, genetrates raw parse tree, rewrites it for certain purpose and generates text query. If you are interested, you could take a look at pgpool-II source code. -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
