Re: [COMMITTERS] pgsql: Un-break pg_dump for the case of zero-column tables.
От | Tom Lane |
---|---|
Тема | Re: [COMMITTERS] pgsql: Un-break pg_dump for the case of zero-column tables. |
Дата | |
Msg-id | 8596.1267029050@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [COMMITTERS] pgsql: Un-break pg_dump for the case of zero-column tables. (Andrew Dunstan <andrew@dunslane.net>) |
Список | pgsql-hackers |
Andrew Dunstan <andrew@dunslane.net> writes: > Tom Lane wrote: >> I think it would make sense to add it as a buildfarm phase, probably >> after installcheck not check so you still have a working postmaster. >> I'm not sure how easy it'd be to automate though. What I usually do >> is make a text dump, restore the dump into an empty DB (watching for >> errors), dump that, and diff the two dumps. However the expected >> diff is not empty because of some tests that intentionally stress >> inheritance column order, and I'm not sure whether it is stable >> enough to use a simple expected-result comparison. > One for this purpose would have to be somewhat more involved than this > example, since we'd need to invent a success measure, which "make" > already gives us for free, and also there are more steps involved than > running a single "make" command. But it should not be terribly > difficult for anyone who wants to try. Actually, given the need for an expected-result file, which could be expected to require maintenance, I suspect that most of the infrastructure for this would have to go into the core source tree anyway. Perhaps a "make install-check-pg_dump" target in src/regress? regards, tom lane
В списке pgsql-hackers по дате отправления: