Hi,
Been playing with the 7.3beta1 version and I've noticed a small
problem with dependency checking when dropping a column. If you have
a view which uses JOIN's to join tables then dropping a column will
fail on a dependency check, even though the column being dropped is
not used at all in the view. If you join the tables in the WHERE
clause the column can be dropped without problems.
Please see below some example SQL to demonstrate:
-- wrap it all up in a transaction so we don't do anything permanent
BEGIN;
CREATE TABLE table1 (col_a text, col_b int);
CREATE TABLE table2 (col_b int, col_c text);
CREATE VIEW tester1 AS SELECT A.col_a,B.col_b FROM table1 A, table2 B
WHERE (b.col_b=a.col_b);
CREATE VIEW tester2 AS SELECT A.col_a,B.col_b FROM table2 B INNER JOIN
table1 A ON (b.col_b=a.col_b);
--Now try and drop column col_c from table2
ALTER TABLE table2 DROP COLUMN col_c RESTRICT;
--You should now get an error to say that col_c is a dependent object
in view tester2
ROLLBACK;
-- I have also noticied the following behaviour when using the SET
command with incorrect option names
SET anythingyoulike = 1,2
--will cause the error to be reported as ERROR: SET anythingyoulike
takes only one argument
SET anythingyoulike = 1
--will cause the error to be reported correctly ('anythingyoulike' is
not a valid option name)
