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

From Tom Lane
Subject Re: [GSOC] questions about idea "rewrite pg_dump as library"
Date
Msg-id 818.1365688274@sss.pgh.pa.us
Whole thread Raw
In response to Re: [GSOC] questions about idea "rewrite pg_dump as library"  (Pavel Golub <pavel@microolap.com>)
Responses Re: [GSOC] questions about idea "rewrite pg_dump as library"
Re: [GSOC] questions about idea "rewrite pg_dump as library"
List pgsql-hackers
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.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: Inconsistent DB data in Streaming Replication
Next
From: Ants Aasma
Date:
Subject: Re: Inconsistent DB data in Streaming Replication