From: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
---|---|
To: | "Boget, Chris" <chris(at)wild(dot)net> |
Cc: | "'''pgsql-general(at)postgresql(dot)org' ' '" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Constraints/On Delete... |
Date: | 2003-01-04 17:23:07 |
Message-ID: | 20030104091836.Y21507-100000@megazone23.bigpanda.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Sat, 4 Jan 2003, Boget, Chris wrote:
> > ALTER TABLE "second" DROP CONSTRAINT "$1";
>
> So the reason mine wasn't working (which looks exactly
> like yours) is because there was the above constraint on
> the table? What is the $1? How can I view the existing
> constraints for any particular table?
Not quite. In your example, you had foreign key (record_num)
references "first"("record_num") which wasn't the correct column to be
referencing from so the data didn't line up correctly.
"$1" is the default name for the first unnamed check/fk constraint on the
table (as of 7.3).
and I think \d <table> will show the constraints now.
> > No. Referential actions are applied on changes to the primary
> > key side of the constraint (in this case "first"), so deletes
> > from first cause actions on second.
>
> Ok, I just wanted to make sure. It just looked like it was the
> other way around. Because it appeared that the pointer (the
> "references") was going from "second" to "first". I guess that
> when records are deleted from the "first", it asks what tables are
> referencing one of it's columns and it's not that it implicitely
> already knows..?
When the constraint is added, triggers are added to first that do the
action or check against second.
From | Date | Subject | |
---|---|---|---|
Next Message | am | 2003-01-04 17:26:17 | Re: postmaster.pid |
Previous Message | Boget, Chris | 2003-01-04 17:18:18 | Re: Constraints/On Delete... |