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

On 04/11/2013 09:51 AM, Tom Lane wrote:
> Pavel Golub <pavel(at)microolap(dot)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