Hmmmm...I wrote the below and then tested it to verify the situation. Unfortunately this sample gives a consistent
'dependson table articles' message rather the mixture I've actually written after the sql. As I'm really not sure what
thedifference is, the only other example possible to give is the full, real schema which I'd rather not at this stage,
somy question morphs into:
Why does dropping a table for some dependencies give notice that the table is depended upon and for other dependencies
thatthe primary key index for the table is depended upon?
This is 7.3.1, all the tables are in the same schema.
===
Included to help visualise the above question even though it does seem to produce the situation.
Given the schema:
create table articles (
id serial primary key
);
create table first_article_referer (
article_id integer not null
references articles ( id )
,another integer
,primary key ( article_id, another )
);
create table second_article_referer (
article_id integer
references articles ( id )
,primary key ( article_id, another )
);
Why does drop table articles yield:
NOTICE: constraint $1 on table first_article_referer depends on table articles
NOTICE: constraint $1 on table second_article_referer depends on index articles_pkey
?
There are more tables like second_article_referer, and ones where the article_id isn't in the primary key, and all have
thesame articles_pkey dependency not just the articles dependency listed for the first_articles_referer.
Is the only cause of this the explicit not null constraint in the first referer?
--
Nigel J. Andrews
