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

Hello, 帅.

You wrote:

帅> Hi all,
帅>     I'd like to introduce myself to the dev community. I am Shuai
帅> Fan, a student from Dalian University of Technology, DLUT , for
帅> short, China. And I am interested in working with PostgreSQL project in GSOC2013.
帅>     I'm interested in the idea "Rewrite (add) pg_dump and
帅> pg_restore utilities as libraries (.so, .dll & .dylib)".

帅>     These days, I had a talk with Mr. Pavel Golub by email, the
帅> author of this post. And asked some questions about this idea. He
帅> adviced me to post the question to this mail list.

帅>     My question is:
帅>     There are lots of functions in "pg_dump.c". If I rewrite this
帅> file as library. I should split "pg_dump.c" into two or more
帅> files(Mr. Pavel Golub's advice). However, some functions, do have return value. e.g.

帅>     static DumpableObject *createBoundaryObjects(void);

帅>     I thought, these functions must get return value through
帅> function argument by passing pointer to it, when using library.
帅> But, the question is: If I did so, function prototype may be
帅> changed. And Mr. Pavel Golub said "it's better to keep all
帅> functions with the same declaration", and so "we will only have one
帅> code base for both console application and library". I think he is right.
帅>     But then, how can I deal with this situation? From my point of
帅> view, I can't malloc a variable (e.g. DumpableObject) in one
帅> library (e.g. pg_dumplib.so), and then return it's pointer to
帅> another library (or excutable program). Maybe, it's not safe(?). Or
帅> has something to do with "memory leak"(?). I'm not sure.
帅>
帅>     Do you have any suggestions?

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);

Return type may be other, but ExecStatusType seems to be OK for this
purpose: PGRES_TUPLES_OK - for success, PGRES_FATAL_ERROR - for fail.

Parameters will remain the same as usual command-line options for
pg_dump. Thus we will have less work for existing application, e.g.
pgAdmin.

2. Logging or notice processing function:

typedef void (*PGdumplogProcessor) (char *relname, int done, char *message);

PGdumplogProcessor PQsetNoticeProcessor(PGdumplogProcessor proc,                    void *arg);

The purpose of this function is process output of the dump. The first
argument is callback-function which accepts information about current
relname (or operation, or stage), done indicates how much work done
(for progress bars etc.), message contains some extra information.

That's all! Only two functions. Indeed we don't need all those
low-level dump functions like createBoundaryObjects etc. There will be
the only one entry to the whole logic. And if one wants the only one
table, funcction or schema - combination of correct parameters should
be passed to PGdumpdbParams.

帅> Best wishes,
帅>     Shuai




--
With best wishes,Pavel                          mailto:pavel@gf.microolap.com