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 по дате отправления: