Re: ALTER TABLE
От | Tom Lane |
---|---|
Тема | Re: ALTER TABLE |
Дата | |
Msg-id | 11490.965322235@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | ALTER TABLE (Gena Gurchonok <gena@rt.mipt.ru>) |
Список | pgsql-bugs |
Stephan Szabo <sszabo@megazone23.bigpanda.com> writes: >> Yes, this is a known bug. Two bugs actually, first being that the >> trigger definitions don't track the rename (they should probably be >> storing OID not relname, although that would complicate dump/restore). > I do plan on trying to move all the table/attribute storage to OIDs. > I actually don't think it'll be too hard on dump/restore, since they > should be able to get rewritten as an ALTER TABLE ADD CONSTRAINT > rather than the CREATE CONSTRAINT TRIGGER, so it should just be > a matter of turning the oids back into rel/attrib names at dump time. That's doable, certainly, but I think it will be a little bit fragile. How will pg_dump know which arguments of which triggers need to be processed in this fashion? Some ugly hardwired assumptions will be needed AFAICS. I think this ties into the discussions we've had on-and-off about not storing enough metadata. It'd be better if the FK constraints were stored explicitly in some system table or other, in a form designed for inspection, and not solely stored in a form designed for execution. It's the same kind of problem we have with SERIAL columns... regards, tom lane
В списке pgsql-bugs по дате отправления: