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
- Enable the mechanical selection of subgraphs which may or may not be
- 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
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.)
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: