[COMMITTERS] pgsql: Un-break pg_dump for thecase of zero-column tables.
in [PgSql]
|
Prev: [COMMITTERS] pgsql: Un-break pg_dump for the case of zero-column tables.
Next: [COMMITTERS] pgsql: Un-break pg_dump for the case ofzero-column tables.
From: Bruce Momjian on 24 Feb 2010 10:23 Tom Lane wrote: > 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. I use that method to test pg_migrator and I always had to edit the dump to remove a few items that always varied. -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |