Re: [GSOC] questions about idea "rewrite pg_dump as library" - Mailing list pgsql-hackers

From Tatsuo Ishii
Subject Re: [GSOC] questions about idea "rewrite pg_dump as library"
Date
Msg-id 20130412.092922.406073591352453323.t-ishii@sraoss.co.jp
Whole thread Raw
In response to Re: [GSOC] questions about idea "rewrite pg_dump as library"  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
>> > 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



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [GSOC] questions about idea "rewrite pg_dump as library"
Next
From: Jeff Janes
Date:
Subject: Re: [ADMIN] after 9.2.4 patch vacuumdb -avz not analyzing all tables