Re: pg_dump.c

On Sun, Sep 11, 2011 at 9:18 AM, Andrew Dunstan <andrew(at)dunslane(dot)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
wultsch(at)gmail(dot)com