Re: [COMMITTERS] pgsql: Un-break pg_dump for the case of zero-column tables.
От | Bruce Momjian |
---|---|
Тема | Re: [COMMITTERS] pgsql: Un-break pg_dump for the case of zero-column tables. |
Дата | |
Msg-id | 201002241523.o1OFNhM04572@momjian.us обсуждение исходный текст |
Ответ на | Re: [COMMITTERS] pgsql: Un-break pg_dump for the case of zero-column tables. (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Tom Lane wrote: > Magnus Hagander <magnus@hagander.net> writes: > > 2010/2/24 Tom Lane <tgl@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@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.comPG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do + If your life is a hard drive,Christ can be your backup. +
В списке pgsql-hackers по дате отправления: