Skip site navigation (1) Skip section navigation (2)


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com>
Cc: Gena Gurchonok <gena(at)rt(dot)mipt(dot)ru>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: ALTER TABLE
Date: 2000-08-03 17:03:55
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)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 by date

Next:From: Roland RobertsDate: 2000-08-03 17:40:13
Subject: RPM buglet, postgres-devel
Previous:From: Tom LaneDate: 2000-08-03 15:52:20
Subject: Re: ALTER TABLE

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group