SELECT * in a CREATE VIEW statement doesn't update column set automatically

Поиск
Список
Период
Сортировка
От Joseph Adams
Тема SELECT * in a CREATE VIEW statement doesn't update column set automatically
Дата
Msg-id u2ze7e5fefd1005061201w162c0a9bye445e0ca1377a0d9@mail.gmail.com
обсуждение исходный текст
Ответы Re: SELECT * in a CREATE VIEW statement doesn't update column set automatically  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: SELECT * in a CREATE VIEW statement doesn't update column set automatically  (Merlin Moncure <mmoncure@gmail.com>)
Список pgsql-hackers
This isn't exactly a bug, but it could be considered unintuitive
behavior.  Consider this:

CREATE VIEW foo AS SELECT * FROM a;
CREATE VIEW foo_v AS SELECT * FROM foo;
ALTER TABLE foo ADD COLUMN b INT;

The ALTER TABLE statement affects VIEW foo, but the column addition
does not propagate to VIEW foo_v.  Thus, it makes this deceptive:

... AS SELECT * FROM foo;

I ran into this with an application where a real table is accessed if
the user is an "admin", while regular users access a view instead.  I
considered "AS SELECT * FROM foo" to be a promise that all columns
from foo would be included in the view, but the promise is broken when
ADD COLUMN is applied later on.

Would it be a desirable feature to make `CREATE VIEW foo_v AS SELECT *
FROM foo;` automatically update the column set when foo's columns
change?  Instead of the wildcard * being expanded once at CREATE VIEW
time, it would (semantically) be expanded every time foo_v is selected
on.


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: max_standby_delay considered harmful
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: max_standby_delay considered harmful