Re: patch: Add columns via CREATE OR REPLACE VIEW
От | Robert Haas |
---|---|
Тема | Re: patch: Add columns via CREATE OR REPLACE VIEW |
Дата | |
Msg-id | 603c8f070812011748p541f8593k57737d04554c15d5@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: patch: Add columns via CREATE OR REPLACE VIEW (Bernd Helmle <mailings@oopsware.de>) |
Ответы |
Re: patch: Add columns via CREATE OR REPLACE VIEW
|
Список | pgsql-hackers |
> I had a deeper look at this now. The patch looks clean and applies without > any problems, regression tests passes. However, ATRewriteTables() has a > problem when adding columns with domains and constraints. Consider this > small test case: > > CREATE TABLE bar (id INTEGER); > CREATE OR REPLACE VIEW vbar AS SELECT * FROM bar; > CREATE DOMAIN person AS TEXT CHECK(value IN ('haas', 'helmle')); > ALTER TABLE bar ADD COLUMN name person; > CREATE OR REPLACE VIEW vbar AS SELECT * FROM bar; > > The last command confuses ATRewriteTable(), which wants to scan the relation > leading to this error: > ERROR: could not open relation base/16384/16476: > > I see that ATRewriteTable() errors out on heap_beginscan(), since needscan > is set to TRUE. One solution would be to teach ATRewriteTable(s) to handle > view alteration differently in this case. After looking at this, I think the root cause of this problem is that ATPrepAddColumn isn't smart enough to know that when the underlying relation is a view, there's no point in asking for a table rewrite. Please find an updated patch that addresses this problem. Thanks again for the review - let me know what you think of this version! ...Robert
Вложения
В списке pgsql-hackers по дате отправления: