On Thu, 5 Dec 2002, Dan Langille wrote: > On 5 Dec 2002 at 9:02, Stephan Szabo wrote: > > > On Thu, 5 Dec 2002, Dan Langille wrote: > > > > > Found the solution: > > > > > > drop trigger "RI_ConstraintTrigger_4278488" on watch_list_staging; > > > > Actually there are three triggers for the constraint. You may have > > dangling triggers on the other table of the constraint. It's one on the > > table the constraint's defined on and two on the referenced table. > > > > > Given that the FK in question did not have a name to start with, I > > > concede that it would be difficult to code DROP FOREIGN KEY. > > > > > > What about supporting ALTER TABLE <table> ADD FOREIGN KEY <keyname> > > > ... which at present we don't? That would then make dropping the FK > > > a simple coding issue? > > > > ISTM, that's > > ALTER TABLE <table> ADD CONSTRAINT <name> FOREIGN KEY ... > > which should be there in any 7.x. > > Agreed. But the syntax is different. If we are supporting "ALTER > TABLE <table> ADD FOREIGN KEY " without a name, why not support it > with a name?
When we talk about ALTER TABLE ADD FOREIGN KEY we're being imprecise, so I think that might be why we're talking past each other here. Technically the syntax in question is: ALTER TABLE <table> ADD <table constraint definition> where CONSTRAINT <name> is an optional leading clause in a table constraint definition. ADD FOREIGN KEY is a shorthand for a foreign key constraint (technically unnamed). Thus you can also say things like: ALTER TABLE <table> ADD CONSTRAINT blah CHECK (foo!=0); to make a named check constraint. ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]