Re: referencial integrity constraint bug in version 7.0 beta 55

From: JanWieck(at)t-online(dot)de (Jan Wieck)
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Jan Wieck <wieck(at)debis(dot)com>, Vassiliadis Spyros <aceteam(at)it(dot)teithe(dot)gr>, pgsql-general(at)postgresql(dot)org
Subject: Re: referencial integrity constraint bug in version 7.0 beta 55
Date: 2000-05-01 21:41:19
Message-ID: 200005012141.XAA08439@hot.jw.home
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Peter Eisentraut wrote:
> Jan Wieck writes:
>
> > Deny column dropping if column in question is used by an
> > FK constraint.
>
> Actually, all the DROP commands in SQL have a RESTRICT/CASCADE choice that
> ought to take care of this. Unfortunately, the PostgreSQL behavior is more
> like `dangle' with an occasional `restrict' but nothing really consistent.
>
> > Propagate column or table renaming to FK constraints.
>
> Don't you refer to them by oid?

No, they are table and attribute name strings given to the
trigger as arguments.

> > Emit a warning if at FK creation time no UNIQUE index
> > exists over referenced PK attributes.
>
> That should actually be an error. (SQL clause 11.8 Syntax rule 2)

Yes, I know. And then we need to deny index dropping while FK
constraints need it in last consequence.

That'd force the user to require dropping/recreating all FK
constraints if he needs to repair (i.e. drop/recreate) one of
those indices. That's why I suggest some non-compliance here.

Jan

--

#======================================================================#
# 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

Browse pgsql-general by date

  From Date Subject
Next Message Marc Tardif 2000-05-01 22:37:15 Re: install question
Previous Message Jan Wieck 2000-05-01 21:30:57 Re: PL/pgSQL: "record not assigned yet" meaning?