Re: [GSOC] questions about idea "rewrite pg_dump as library"
От | Tatsuo Ishii |
---|---|
Тема | Re: [GSOC] questions about idea "rewrite pg_dump as library" |
Дата | |
Msg-id | 20130412.092922.406073591352453323.t-ishii@sraoss.co.jp обсуждение исходный текст |
Ответ на | Re: [GSOC] questions about idea "rewrite pg_dump as library" (Michael Paquier <michael.paquier@gmail.com>) |
Список | 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 по дате отправления: