Re: [COMMITTERS] pgsql: Un-break pg_dump for the case of zero-column tables. - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [COMMITTERS] pgsql: Un-break pg_dump for the case of zero-column tables.
Date
Msg-id 6542.1267023174@sss.pgh.pa.us
Whole thread Raw
Responses Re: [COMMITTERS] pgsql: Un-break pg_dump for the case of zero-column tables.  (Bruce Momjian <bruce@momjian.us>)
Re: [COMMITTERS] pgsql: Un-break pg_dump for the case of zero-column tables.  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
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.

Still, if anyone who knows the buildfarm code cares to try that,
I'd be all for it.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Gokulakannan Somasundaram
Date:
Subject: Re: A thought on Index Organized Tables
Next
From: Robert Haas
Date:
Subject: Re: A thought on Index Organized Tables