>> > 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