Re: [GSOC] questions about idea "rewrite pg_dump as library"

On 04/11/2013 09:51 AM, Tom Lane wrote:
> Pavel Golub <pavel@microolap.com> writes:
>>  From my point of view the new library should export only two
>> functions:
>> 1. The execution function:
>> ExecStatusType PGdumpdbParams(const char * const *keywords,
>>                   const char * const *values);
> No, this is exactly *wrong*.  You might as well not bother to refactor,
> if the only API the library presents is exactly equivalent to what you
> could get with system("pg_dump ...").
>
> I don't know what the right answer is, but this isn't it.  Most people
> who are interested in this topic are interested because they want to get
> output that is different from anything pg_dump would produce on its own,
> for instance applying a more complex object-selection rule than anything
> pg_dump offers.  Right now, the only way they can do that is lobby to
> add new switch options to pg_dump.  With a change like this, it'd still
> be the case that they can't get what they want except by adding new
> switch options to pg_dump.  I don't see any advantage gained.
>
>             



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. Last year I started writing a package to provide such 
functions, which i called RetailDDL, and it was well received at the 
conference where I talked about it, but I have not had time since then 
to work on it, as JSON development among other things has had a rather 
higher priority. But I think it's very well worth doing. I think in 
principle having database functions for the creation DDL for its own 
objects is a good idea.

And yes, that would mean keeping knowledge of how to produce such output 
in two places - pg_dump is going to need to keep historical knowledge, 
for one thing. But I can live with that.

It could be interesting to have a library that would output database 
metadata in some machine readable and manipulatable format such as JSON 
or XML. One thing that's annoying about the text output pg_dump produces 
is that it's not at all structured, so if you want, for example, to 
restore a table but to a table of a different name, or to a different 
schema, then you're reduced to having to mangle the SQL by using hand 
editing or regular expression matching. Something with the potential to 
ease that pain would be worth having.

cheers

andrew