From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | David Fetter <david(at)fetter(dot)org> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_dump.c |
Date: | 2011-09-11 16:18:40 |
Message-ID: | 4E6CDF60.9000904@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-09-11 18:50:06 | Re: pg_dump.c |
Previous Message | Robert Haas | 2011-09-11 15:26:59 | Re: pg_dump.c |