On 06/24/2013 03:39 PM, Tom Lane wrote:
Robert Haas writes:
We probably do need to preserve attribute numbers across an upgrade,
even for foreign tables. I think those could make their way into
other places.
Hm ... this argument would also apply to composite types; do we get it
right for tho
Robert Haas writes:
> We probably do need to preserve attribute numbers across an upgrade,
> even for foreign tables. I think those could make their way into
> other places.
Hm ... this argument would also apply to composite types; do we get it
right for those?
regards,
On Sat, Jun 22, 2013 at 3:55 PM, Andrew Dunstan wrote:
>> Essentially, cross version upgrade testing runs pg_dumpall from the new
>> version on the old cluster, runs pg_upgrade, and then runs pg_dumpall on the
>> upgraded cluster, and compares the two outputs. This is what we get when the
>> new v
On 06/20/2013 11:16 AM, I wrote:
On 06/20/2013 10:43 AM, Robert Haas wrote:
On Tue, Jun 18, 2013 at 12:18 PM, Andrew Dunstan
wrote:
As I was updating my cross version upgrade tester to include support
for the
9.3 branch, I noted this dump difference between the dump of the
original
9.3 data
On 06/20/2013 10:43 AM, Robert Haas wrote:
On Tue, Jun 18, 2013 at 12:18 PM, Andrew Dunstan wrote:
As I was updating my cross version upgrade tester to include support for the
9.3 branch, I noted this dump difference between the dump of the original
9.3 database and the dump of the converted d
On Tue, Jun 18, 2013 at 12:18 PM, Andrew Dunstan wrote:
> As I was updating my cross version upgrade tester to include support for the
> 9.3 branch, I noted this dump difference between the dump of the original
> 9.3 database and the dump of the converted database, which looks odd. Is it
> correct
As I was updating my cross version upgrade tester to include support for
the 9.3 branch, I noted this dump difference between the dump of the
original 9.3 database and the dump of the converted database, which
looks odd. Is it correct?
cheers
andrew
--- /home/bf/bfr/root/upgrade/HEAD/origin-
