Re: [HACKERS] pg_dump not in very good shape

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] pg_dump not in very good shape
Дата
Msg-id 20076.948091111@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] pg_dump not in very good shape  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
Peter Eisentraut <peter_e@gmx.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] Temp Table Memory Leak
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] flex