From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] pg_dump not in very good shape |
Date: | 2000-01-17 06:38:31 |
Message-ID: | 20076.948091111@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Which brings up the idea why the regression tests don't test pg_dump.
That'd be nice ...
> Would it not be a decent idea to do a
> pg_dump regress > out
> diff out expected.out
> at the end of the tests?
There's a couple of small practical problems with that. Number one:
pg_dump regression | wc
118211 565800 3516170
Adding a 3.5meg comparison file to the distribution isn't too
appetizing; nor is the prospect of trying to keep it up to date
via cvs. (*How* much storage did you just add to hub, Marc? ;-))
Number two is that we'd never get consistent dump results across
different platforms. There are the known cross-platform variations
(float roundoff, DST handling, etc) already accounted for by
platform-specific substitute comparison files. Worse, a dump will
see the platform-dependent variations in tuple update order that we
currently mask in many tests by asking for ordered select results.
I don't think anyone will hold still for a bunch of 3.5meg
platform-specific dump comparison files.
In short, it'd be a great idea, but figuring out a practical testing
method will take some work.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-01-17 06:41:28 | Re: [HACKERS] flex |
Previous Message | Tom Lane | 2000-01-17 06:29:16 | Re: [HACKERS] pg_dump not in very good shape |