From: | Pavel Golub <pavel(at)microolap(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Pavel Golub <pavel(at)microolap(dot)com>, 帅 <shuai900217(at)126(dot)com>, "'PostgreSQL-development'" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [GSOC] questions about idea "rewrite pg_dump as library" |
Date: | 2013-04-11 14:51:09 |
Message-ID: | 1166087219.20130411175109@gf.microolap.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello, Tom.
You wrote:
TL> 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);
TL> No, this is exactly *wrong*. You might as well not bother to refactor,
TL> if the only API the library presents is exactly equivalent to what you
TL> could get with system("pg_dump ...").
Well, yes. You're absolutely right. But should this be a starting
point?
TL> I don't know what the right answer is, but this isn't it. Most people
TL> who are interested in this topic are interested because they want to get
TL> output that is different from anything pg_dump would produce on its own,
TL> for instance applying a more complex object-selection rule than anything
TL> pg_dump offers. Right now, the only way they can do that is lobby to
TL> add new switch options to pg_dump. With a change like this, it'd still
TL> be the case that they can't get what they want except by adding new
TL> switch options to pg_dump. I don't see any advantage gained.
TL> regards, tom lane
--
With best wishes,
Pavel mailto:pavel(at)gf(dot)microolap(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Ants Aasma | 2013-04-11 15:09:32 | Re: Inconsistent DB data in Streaming Replication |
Previous Message | Bruce Momjian | 2013-04-11 14:48:50 | Nearing beta? |