Re: pg_dump.c
От | Andrew Dunstan |
---|---|
Тема | Re: pg_dump.c |
Дата | |
Msg-id | 4E6CDF60.9000904@dunslane.net обсуждение исходный текст |
Ответ на | Re: pg_dump.c (David Fetter <david@fetter.org>) |
Ответы |
Re: pg_dump.c
Re: pg_dump.c |
Список | pgsql-hackers |
On 09/11/2011 10:25 AM, David Fetter wrote: > On Thu, Sep 08, 2011 at 03:20:14PM -0400, Andrew Dunstan wrote: >> In the "refactoring Large C files" discussion one of the biggest >> files Bruce mentioned is pg_dump.c. There has been discussion in the >> past of turning lots of the knowledge currently embedded in this >> file into a library, which would make it available to other clients >> (e.g. psql). I'm not sure what a reasonable API for that would look >> like, though. Does anyone have any ideas? > Here's a sketch. > > In essence, libpgdump should have the following areas of functionality: > > - Discover the user-defined objects in the database. > - Tag each as pre-data, data, and post-data. > - Make available the dependency graph of the user-defined objects in the database. > - Enable the mechanical selection of subgraphs which may or may not be connected. > - Discover parallelization capability, if available. > - Dump requested objects of an arbitrary subset of the database, > optionally using such capability. > > Then there's questions of scope, which I'm straddling the fence about. > Should there be separate libraries to transform and restore? > > A thing I'd really like to have in a libdump would be to have the > RDBMS-specific parts as loadable modules, but that, too, could be way > out of scope for this. > > In the first place, this isn't an API, it's a description of functionality. A C library's API is expressed in its header files. Also, I think you have seriously misunderstood the intended scope of the library. Dumping and restoring, parallelization, and so on are not in the scope I was thinking of. I think those are very properly the property of pg_dump.c and friends. The only part I was thinking of moving to a library was the discovery part, which is in fact a very large part of pg_dump.c. One example of what I'd like to provide is something this: char * pg_get_create_sql(PGconn *conn, object oid, catalog_class oid, pretty boolean); Which would give you the sql to create an object, optionally pretty printing it. Another is: char * pg_get_select(PGconn *conn, table_or_view oid, pretty boolean, alias *char ); which would generate a select statement for all the fields in a given table, with an optional alias prefix. For the purposes of pg_dump, perhaps we'd want to move all the getFoo() functions in pg_dump.c into the library, along with a couple of bits from common.c like getSchemaData(). (Kinda thinking out loud here.) cheers andrew
В списке pgsql-hackers по дате отправления: