[COMMITTERS] pgsql: Un-break pg_dump for the case of zero-column tables.
in [PgSql]
|
Prev: FW: Unable to install PostgreSQL on Windows Server 2003 SP2
Next: [COMMITTERS] pgsql: Un-break pg_dump for thecase of zero-column tables.
From: Tom Lane on 24 Feb 2010 09:52 Magnus Hagander <magnus(a)hagander.net> writes: > 2010/2/24 Tom Lane <tgl(a)postgresql.org>: >> Log Message: >> ----------- >> Un-break pg_dump for the case of zero-column tables. >> >> This was evidently broken by the CREATE TABLE OF TYPE patch. �It would have >> been noticed if anyone had bothered to try dumping and restoring the >> regression database ... > Is there a point in doing that at the end of "make check"? Or as a > separate step on the buildfarm? 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. Still, if anyone who knows the buildfarm code cares to try that, I'd be all for it. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 24 Feb 2010 11:30
Andrew Dunstan <andrew(a)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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |