Robert Haas wrote:
On Mon, Aug 2, 2010 at 2:56 PM, Yeb Havinga <yebhavi...@gmail.com> wrote:
Hence the ATOneLevelRecursion routing is usable in its
current form for all callers during the prep stage, and not only
ATPrepAddColumn.
Well, only if they happen to want the "visit each table only once"
behavior, which might not be true for every command type.
It is actually "visit each table only once for each distinct parent".
Looking at the command types for ALTER TABLE, I see none where this
behaviour would be incorrect.
That put aside, the top1/top2 example is interesting in the sense that
it reveals other problems besides the wrong attinhcount at the basement.
For an example see the script below. The underlying cause is the failure
of the code to recognize that if relation C inherits from both A and B,
where A and B both have column x, that A.x 'is the same as' B.x, where
the 'is the same as' relation is the same that holds for (A.x, C.x) and
(B.x, C.x), which the code does a lot of trouble for to recognize. This
means that if some definition is altered on A.x, only C.x is updated and
B.x not touched. IMO this is wrong and either a multiple inheritance
structure like this should be prohibited, since the user did not
explicitly declare that A.x and B.x 'are the same' (by e.g. defining a
relation D.x and have A and B inherit from that), or the code should
update parents of relations when the childs are updated.
The difficulty is in exactly specifying the 'is the same' as relation,
i.e. under what conditions are columns A.x and B.x allowed to be merged
to C.x. In the regression test there's only a small amount of tests, but
one of them shows that the 'is the same' as relation does not mean
everything is the same, as it shows that default values may differ.
regards,
Yeb Havinga
DROP SCHEMA IF EXISTS test_inheritance CASCADE;
CREATE SCHEMA test_inheritance;
SET search_path TO test_inheritance;
CREATE TABLE top1 (i int);
CREATE TABLE top2 (i int);
CREATE TABLE bottom () INHERITS (top1, top2);
CREATE TABLE basement () INHERITS (bottom);
ALTER TABLE top1 ADD COLUMN a_table_column INTEGER;
ALTER TABLE top2 ADD COLUMN a_table_column INTEGER;
SELECT t.oid, t.relname, a.attinhcount, a.attname
FROM pg_class t
JOIN pg_attribute a ON (a.attrelid = t.oid)
JOIN pg_namespace n ON (t.relnamespace = n.oid)
WHERE n.nspname = 'test_inheritance' AND a.attname LIKE '%table_column%'
ORDER BY oid;
ALTER TABLE top1 RENAME COLUMN a_table_column TO another_table_column;
SELECT t.oid, t.relname, a.attinhcount, a.attname
FROM pg_class t
JOIN pg_attribute a ON (a.attrelid = t.oid)
JOIN pg_namespace n ON (t.relnamespace = n.oid)
WHERE n.nspname = 'test_inheritance' AND a.attname LIKE '%table_column%'
ORDER BY oid;
ALTER TABLE top2 RENAME COLUMN a_table_column TO another_table_column;
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
