Return-Path: mao
Received: by postgres.Berkeley.EDU (5.61/1.29)
	id AA00089; Mon, 20 Jul 92 15:03:38 -0700
Message-Id: <9207202203.AA00089@postgres.Berkeley.EDU>
From: <mao@postgres.berkeley.edu>
Subject: order of attributes in inheritance schemata in postgres 3.1, 4.0
To: postgres@postgres.berkeley.edu
Sender: pg_adm@postgres.berkeley.edu
Date: Mon, 20 Jul 92 15:14:38 PDT

bill miller, at the us geological survey, writes

> Thank you for your offer of an awk script to reorder the
> attributes for copying iour data from version 3.1 to version 4.0.
> I do not need the script, but would like to know how to
> determine the ordering for future reference. I think that
> the people on the general mailing list would be interested
> as well. This information might make a good contribution to the
> reference manual in the future. 

here's the story:

in version 3.1, when you created a class with inheritance, the
order of attributes in the child was as follows:

    first, all attributes declared explicitly for the child;
    next, attributes of parent classes in the create statement,
	in left-to-right order from the 'inherits' clause.

for example, in 3.1, the schema declaration

	create A (a1 = int4, a2 = int4)
	create B (b1 = int4, b2 = int4)
	create C (c1 = int4, c2 = int4) inherits (A, B)

would yield the following attribute order in class C:

	c1, c2, a1, a2, b1, b2

in 4.0, the same declaration yields

	a1, a2, b1, b2, c1, c2

that is, in v4.0, the rule is

    first, parents' attributes are inherited from classes in the
	'inherits' clause, left-to-right;
    next, all new attributes declared for the child appear.

of course, this applies transitively, as well.  in version 3.1, if you
had said

	create A (a = int4)
	create B (b = int4) inherits (A)
	create C (c = int4) inherits (B)

the order of attributes in C would have been

	c, b, a

in 4.1, the order is

	a, b, c

this change was made because it appeared sensible to us to have
structural equivalence among tuples in a single-inheritance hierarchy.
so far, everyone who's noticed the change has been confused by it.
since tuple structure should be invisible to the user, we clearly
messed this up.

however, having made the mistake once, we're very unlikely to change
things back to the way they were before.  if you have any questions
about the ordering, particularly for copying data among postgres versions,
don't hesitate to contact us.  "us" is bug-postgres@postgres.

					mike olson
					project sequoia 2000
					uc berkeley
					mao@cs.berkeley.edu