Skip site navigation (1) Skip section navigation (2)

Re: pg_dump.c

From: Rob Wultsch <wultsch(at)gmail(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: David Fetter <david(at)fetter(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_dump.c
Date: 2011-09-11 19:33:28
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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

In response to

pgsql-hackers by date

Next:From: Devrim GÜNDÜZDate: 2011-09-11 19:44:30
Subject: Re: Alpha 1 for 9.2
Previous:From: Alexander KorotkovDate: 2011-09-11 19:30:11
Subject: Double sorting split patch

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group