Re: BUG #3403: ver 8.2 can't add serial column to temp table,but 8.1 can
От | Heikki Linnakangas |
---|---|
Тема | Re: BUG #3403: ver 8.2 can't add serial column to temp table,but 8.1 can |
Дата | |
Msg-id | 467C25C7.4000500@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: BUG #3403: ver 8.2 can't add serial column to temp table,but 8.1 can (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #3403: ver 8.2 can't add serial column to temp table,but 8.1 can
|
Список | pgsql-bugs |
Tom Lane wrote: > This is actually a bit nasty. Your proposed patch doesn't really work, > because of the concern that is now commented at the head of > transformAlterTableStmt: > > * CAUTION: resist the temptation to do any work here that depends on the > * current state of the table. Actual execution of the command might not > * occur till some future transaction. Hence, we do only purely syntactic > * transformations here, comparable to the processing of CREATE TABLE. > > IOW, we don't actually *know* at parse analysis time which table will be > affected. I don't understand that. Why would the execution be delayed to a future transaction? You can't PREPARE an ALTER TABLE, right? According to the comments in transformInhRelation, it has the same problem... > Maybe we should give up doing any CREATE/ALTER processing at all at > parse analysis time, and push it all to execution time. I got rid of > parse-time processing of other utility statements during the plan > caching work a couple months ago, because of concerns very much like > this, but I hadn't bit the bullet for CREATE/ALTER TABLE because it was > such a huge chunk of code. But maybe we'd better do it. We'll still need something smaller to back patch, I think. :( -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-bugs по дате отправления: