Re: ALTER TABLE
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Stephan Szabo <sszabo@megazone23.bigpanda.com>
Cc: Gena Gurchonok <gena@rt.mipt.ru>, pgsql-bugs@postgresql.org
Date: 2000-08-03T17:03:55Z
Lists: 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