To: "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
cc: "Achilleas Mantzios" <achill@matrix.gatewaynet.com>,
	pgsql-admin@postgresql.org
Subject: Re: FK disappeared in 8.3.3 
In-reply-to: <4CEA30A90200002500037CE1@gw.wicourts.gov> 
References: <201011221213.32035.achill@matrix.gatewaynet.com>
	<4CEA30A90200002500037CE1@gw.wicourts.gov>
Comments: In-reply-to "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
	message dated "Mon, 22 Nov 2010 08:58:17 -0600"
Date: Mon, 22 Nov 2010 11:11:12 -0500
Message-ID: <27456.1290442272@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> Achilleas Mantzios <achill@matrix.gatewaynet.com> wrote:
>> I am puzzled about the differences in the schema, if any one has
>> any ideas  of why this might be happening, would be great.
 
> My first guess is that they were dumped by pg_dump executables from
> different versions.

The differences do look suspiciously related to past cross-version
changes.  I do not think they can be explained entirely by pg_dump
differences, though.  In particular, there's no way that pg_dump
could have caused the reported change in a view definition from
ANY(ARRAY[...]) to a list of ORs.  What seems most likely to me is
that that view was originally entered as
	WHERE machclasses.id IN (1, 2, 16, ...)
Backends since 8.2 will translate that into ANY(ARRAY), which is how
it'll get reverse-listed by \d or pg_dump.  Older versions produced
the list-of-ORs translation.  I think the "bad" dump somehow traces
its lineage to an 8.1 or older installation.  The other issues look
like they could possibly be explained by either forcing pg_dump to
dump from a newer server major version (which until recently you
could force with -i, but the resulting dump would likely have issues)
or trying to load a dump script into an older major server version
than it was designed for (and ignoring the ensuing error messages).

			regards, tom lane