Re: [HACKERS] pg_dump not in very good shape - Mailing list pgsql-hackers

From Jan Wieck
Subject Re: [HACKERS] pg_dump not in very good shape
Date
Msg-id 38832FDC.5B5EC18D@debis.com
Whole thread Raw
In response to Re: [HACKERS] pg_dump not in very good shape  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Tom Lane wrote:

> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Actually the megatest is:
>
> >       pg_dump regress > out
> >       dropdb regression
> >       createdb regression
> >       psql regression < out
> >       pg_dump regress > out2
> >       diff out out2
>
> > That is the pg_dump test, and someone usually does it as part of
> > regression testing before each release.
>
> > It would be nice to add this to test/regress/Makefile maybe.
>
> That's a good thought --- it eliminates both the platform-specific
> issues and the problem of adding a bulky reference file to the
> distribution.
    Still an incomplete test at all.
    It doesn't guarantee, that the resulting dump is what you    really need to restore the database. For example, I'm
not   sure that FOREIGN KEY constraints are actually dumped    correct (as constraint trigger statements after the data
  load). So it might work, and result in the same, wrong dump    again.
 



Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#========================================= wieck@debis.com (Jan Wieck) #





pgsql-hackers by date:

Previous
From: Theo Kramer
Date:
Subject: Re: [HACKERS] DefineQueryRewrite: rule plan string too big.
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Foreign keys: unexpected result from ALTER TABLE... ADD CONSTRAINT...