> -----Original Message-----
> From: pgsql-bugs-owner@postgresql.org=20
> [mailto:pgsql-bugs-owner@postgresql.org] On Behalf Of Tom Lane
> Sent: Wednesday, September 10, 2003 6:42 PM
> To: Christoph Jaeger
> Cc: pgsql-bugs@postgresql.org
> Subject: Re: [BUGS] Foreign key constraint still active after=20
> table row removed=20
>=20
>=20
> "Christoph Jaeger" <christoph.jaeger@dhl.com> writes:
> > PostgreSQL version (example: PostgreSQL-7.3.4): postgresql 7.1.3=20=
=20
>=20
> 7.1.3 is ancient history, and no it doesn't have defenses against you
> changing a column definition that a foreign key linkage refers to.
> I'd recommend updating to 7.3.4.
>=20
Ok, so I will upgrade.=20
There are already some invalid constraints in my database due to some
fields I dropped earlier. I only found out about these now, because the
data in these tables is quite static, and I did only INSERTs (which do
not trigger the constraints), no UPDATEs. The problem is, these
constraints get exported in a pg_dump, and, of course, reimported with a
pg_restore. I guess I can solve this by manually editing the dump file
(remove the unneeded CREATE CONSTRAINT statements). Is there a better
way to do this?
Thanks a lot,
Best Regards,
Christoph J=E4ger
> > The table pg_trigger shows three rows, which seem to point=20
> to this no
> > longer valid constraint, but I do not think it is a good=20
> idea to fiddle
> > with this unless one really knows how this all works together.
>=20
> In 7.1, drop the triggers and you're done. AFAIR this would also be
> necessary in 7.2. In 7.3 you could have just dropped the columns you
> wanted to drop, and not had all these problems.
>=20
> regards, tom lane
>=20
> ---------------------------(end of=20
> broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>=20
