Tom Lane wrote:
> >> but a larger question is why the system let you drop a table that
> >> is the target of a referential integrity check (which I assume is
> >> what you did to get into this state).
> > For me too.
> What about renaming as opposed to dropping? Since the triggers are set
> up to use names rather than OIDs, seems like they are vulnerable to a
> rename. Maybe they should be using table OIDs in their parameter lists.
> (That'd make pg_dump's life harder however...)
That at least shows how he might have gotten there. And yes,
they need to either keep track of renamings or use OID's.
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #
In response to
pgsql-hackers by date
|Next:||From: Mikheev, Vadim||Date: 2000-07-11 18:49:06|
|Subject: RE: Storage Manager (was postgres 7.2 features.)|
|Previous:||From: Prasanth A. Kumar||Date: 2000-07-11 18:46:23|
|Subject: Re: Slashdot discussion|
pgsql-bugs by date
|Next:||From: Stephan Szabo||Date: 2000-07-11 19:24:13|
|Subject: Re: Foreign key bugs (Re: [BUGS] "New" bug?? Serious - crashesbackend.)|
|Previous:||From: Bruce Momjian||Date: 2000-07-11 16:03:57|
|Subject: Re: [HACKERS] Foreign key bugs (Re: "New" bug?? Serious - crashes