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

Re: [HACKERS] Foreign key bugs (Re: "New" bug?? Serious - crashes backend.)

From: JanWieck(at)t-online(dot)de (Jan Wieck)
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jan Wieck <JanWieck(at)Yahoo(dot)com>, ryan <ryan(at)bel(dot)bc(dot)ca>, pgsql-bugs(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)orgg
Subject: Re: [HACKERS] Foreign key bugs (Re: "New" bug?? Serious - crashes backend.)
Date: 2000-07-11 18:47:52
Message-ID: 200007111847.UAA19282@hot.jw.home (view raw, whole thread or download thread mbox)
Lists: pgsql-bugspgsql-hackers
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, VadimDate: 2000-07-11 18:49:06
Subject: RE: Storage Manager (was postgres 7.2 features.)
Previous:From: Prasanth A. KumarDate: 2000-07-11 18:46:23
Subject: Re: Slashdot discussion

pgsql-bugs by date

Next:From: Stephan SzaboDate: 2000-07-11 19:24:13
Subject: Re: Foreign key bugs (Re: [BUGS] "New" bug?? Serious - crashesbackend.)
Previous:From: Bruce MomjianDate: 2000-07-11 16:03:57
Subject: Re: [HACKERS] Foreign key bugs (Re: "New" bug?? Serious - crashes backend.)

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