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 по дате отправления: