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

Re: Possible changes to pg_restore

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: hywel(at)hmallett(dot)co(dot)uk, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Possible changes to pg_restore
Date: 2010-01-26 01:34:39
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

Tom Lane wrote:
> <hywel(at)hmallett(dot)co(dot)uk> writes:
>> Would it be possible and worthwhile to add functionality to pg_restore so
>> that with one switch triggers/indexes/constraints could be ignored, and
>> with another switch only triggers/indexes/constraints would be restored?
> You should probably go back and look at the archives from the last
> go-round on that.  I believe it was during the 8.4 devel cycle.
> Somebody (might have been Simon, but not sure) submitted a patch for
> three-part output from pg_dump, it was discussed and sent back for
> revision, and the revision never materialized :-(.  But IIRC there
> was reasonably clear consensus on what the feature ought to look like.

What is more, the changes done for parallel pg_restore actually did some 
of the requisite work of classifying members, as can be seen in this 
definition in pg_dump.h:

    typedef enum _teSection
        SECTION_NONE = 1,           /* COMMENTs, ACLs, etc; can be
    anywhere */
        SECTION_PRE_DATA,           /* stuff to be processed before data */
        SECTION_DATA,               /* TABLE DATA, BLOBS, BLOB COMMENTS */
        SECTION_POST_DATA           /* stuff to be processed after data */
    } teSection;

Of course, you'd need to figure our how to handle the SECTION_NONE 
entries, but other than that it should be pretty simple, I think.



In response to

pgsql-hackers by date

Next:From: Fujii MasaoDate: 2010-01-26 02:08:09
Subject: Re: Dividing progress/debug information in pg_standby, and stat before copy
Previous:From: Tom LaneDate: 2010-01-26 01:26:14
Subject: Re: default_language

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