On Sun, Sep 11, 2011 at 9:18 AM, Andrew Dunstan <and...@dunslane.net> wrote: > > > 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 > > >
For whatever it is worth, the "SHOW CREATE TABLE" command in MySQL is well loved. Having the functionality to generate SQL in the server can be very nice. -- Rob Wultsch wult...@gmail.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
