"Robert Haas" <robertmhaas@gmail.com> writes:
> Imagine for example:
> CREATE TABLE foo (c1 integer, c2 text, c3 boolean, c4 date, c5
> timestamp, c6 numeric, c7 varchar);
> CREATE OR REPLACE VIEW tricky AS SELECT * FROM foo AS bar (a, b, c);
> ALTER TABLE foo ALTER COLUMN c2 POSITION LAST;
> After some thought, it seems pretty clear, at least to me, that the
> third (hypothetical) command should not change the result of "SELECT *
> FROM tricky" (the contrary conclusion gives rise to a lot of problems,
> especially if there are other views depending on it). But what will
> "pg_dump -t tricky" output at this point?
I don't think it's as bad as you fear, because you can always insert
additional aliases that aren't changing the column names. Furthermore,
per spec the column ordering of tricky doesn't change when foo's does.
So immediately after the CREATE VIEW tricky ought to look like
SELECT a, b, c, c4, c5, c6, c7 FROM foo AS bar (a, b, c);
which we could also represent as
SELECT a, b, c, c4, c5, c6, c7 FROM foo AS bar (a, b, c, c4, c5, c6, c7);
and the column position change would morph this into
SELECT a, b, c, c4, c5, c6, c7 FROM foo AS bar (a, c, c4, c5, c6, c7, b);
Now admittedly the current internal representation of alias-lists
doesn't cope with that (unless maybe you consider that list position
corresponds to column identity), but that representation isn't set in
stone.
regards, tom lane